On Sunday, November 28, 1999, Douglas Hinds wrote:
<snip>
> Finally (I am pissed off at this point), I make the rule active *and*
> manual only and boom. It works. For all practical purposes then, *only
> active filters filter*, and they can be manual or not manual.
Your confusion stems from being able to check "Manual only" on the
filters page without having to check active. I suppose this is done to
allow users to activate and deactivate filters that they wish to apply
manually. All filters must have the "Active" option checked to work.
The "Manual filters only" option on the re-filter dialog is intended
only to give you the option of applying only those filters that you have
designated as "Manual only".
> Now, I would assume that have a active rule with manual only means
> that without selecting "manual only" it won't take effect when
> re-filtering, but this is not true - it will anyway.
Right, thus the option on the re-filter dialog for "Manual filters
only". Re-filtering without checking that option will invoke all active
filters, regardless of whether or not the "Manual only" option is
checked for the filter.
So, what you have is:
Active, Manual Only not checked - operate automatically when triggered
by event OR operate on re-filtering if "Manual filters only" is not
selected.
Active, Manual Only checked - operate only on re-filtering. If "Manual
filters only" is selected on re-filtering only these filters will be
invoked.
Filters that are not marked "Active" are deactivated regardless of
whether or not "Manual only" is checked.
> I don't find a consistent logic here.
There is a logic there once you discover it. It doesn't seem
counterintuitive to me that, for example, a filter has to be active to
work.
> I have been lumping Read Messages" and "Replied Messages" in with
> "Incoming Mail" conceptually, when as you point out, these are dealt
> with separately (not included when filtering "Incoming Mail").
This was an error on my part, going back to earlier versions of TB.
Incoming Mail filters do, in fact, operate on _all_ messages in the
InBox when using re-filtering. Sorry to add to the confusion.
> [The following was written *before* the above].
> Also - According to TB!'s "help" file, when two locations are selected
> for a given string, *both* conditions must be satisfied, when I
> assumed that I was filtering for *either* condition. This explains why
> some filters weren't functioning.
All conditions placed in the same rule are AND conditions, with one
exception. An OR condition can be created by using a | between strings
in the same condition, for example, TBUDL|TBBETA can be used to filter
messages from either source to a single folder. I believe the | can only
be used for two strings, however. (I haven't tested it lately.) More
than two OR conditions requires going to the Alternatives.
> Not only that, I wasn't taking into account the alternatives, actions
> and options involved. One of the options permits the use of "regular
> expressions", but I find nothing in the help file that refers directly
> to that
There is nothing in the Help file about this recently added feature and
no one here is sure how to use it, but you don't really need it for most
filtering you normally want to do.
> , although there *is* something on "Special syntax", "used for
> signal strings", which I assume is what that refers to.
No, this doesn't refer to Regular Expression. It refers to syntax that
may used in conditions in any case.
> You mean that it doesn't have to the outbox? Also, do *all* outgoing
> messages from a given account go *through* the outbox?
I believe that Outgoing Mail filters work on all messages sent. All
messages being sent may actually go through the Outbox. I've never
really noticed.
> Here we have good people who are also capable people at all ends. So
> any tech problems will get worked out, although the filtering
> arrangement seems unduly complex and inconsistent (greater consistency
> would simplify complexity) at present, and the time spent on this *is*
> unsustainable, if not resolved soon. ...
> You already get a list of variables in relation to the string, actions
> etc. I think a good html or pdf tutorial would go a long way...
TB is a very good program once you discover what's under the hood, but
that does take some effort. The developers are aware that the Help file
is now out of date and not complete or understandable enough in many
areas. A new Help file is supposedly in the works for version 2. This
list remains the best source for discovering the potential of the
program, which is amazing in some respects. However, people's needs vary
and it is not necessarily the best program for everyone. I use it
primarily because I produce alot of stock replies and form messages and
TB is the best program around for doing that, but I still much prefer
the way my last mailer handled filtering.
PF>> I take it that what you want to do is review most new mail for
PF>> something of particular interest before moving unread messages to
PF>> folders that might contain alot of other unread messages.
> That is exactly right.
You can do this to the extent that you don't want to filter the messages
from the InBox incrementally. You can filter messages incrementally, but
I think you would need to go into the filter properties and make each
filter active in turn, then set them all back to inactive. Hard to say
without actually seeing the messages.
> Regarding the ticker in relation to filtering:
I don't use the ticker.
>>> And how to deal with parked items would have to be dealt with
>>> separately - a separate rule could be invoked.
PF>> There was a long discussion once on moving parked messages. The
PF>> conclusion, I think, was that there should be another category,
PF>> like "Keep", as "Park" should mean "do not delete and do not move".
> The main problem with park is that no other mechanism I know of is now
> available in TB for signaling priority status for *received* mail ...
This issue has been discussed extensively on the list. It is my
understanding also that some sort of flagging features will be in
version 2.
> Damn. I just noticed that when moving messages using drag and drop,
> after TB asks whether parked messages should be moved (it *doesn't*
> ask if you want the park flag removed), it *does* remove it on moving
> it.
Park is not a good substitute for flagging; however, parked messages
will not be filtered, so that can help. The only alternative currently
in TB is to use folders. CTRL-V makes it pretty easy to move messages to
folders as you go along through a long list of messages.
> So there goes all my highlighted-via-the-parked-flagged messages,
> that were accumulated until the amount of mail in the inbox made it so
> slow to open that I *had* to move at least certain lists to their own
> folders. And these had both a lot of things to follow up (flagged
> using the park flag) and a lot more chaff.
I would be so bold as to suggest that if you have that many messages
stored in your InBox that you consider filtering these directly to
folders, then moving or filtering them from there. For example, create a
set of top level folders to handle new messages. When you have time to
look at them, select the ones you want to reply to or are more
interested in for whatever reason, do CTRL-V and move them to a
subfolder, e.g. Important. Then Select All the remainder and move them
to another folder, e.g. Old.
Many things can be accomplished with TB once you start thinking like it
does. :) And, people on the list have lots of good tips and tricks.
--
Paula Ford
The Bat! 1.36 (reg)
Windows 95 4.0 Build 950
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
