(long but substantial)
Hello Paula & all fellow TBUDL members,
>> Finally, 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.
PF> Your confusion stems from being able to check "Manual only" on the
PF> filters page without having to check active.
Is that "my" confusion or is that simply an option not explained in
the TB help file? (Enter the word "manual" in the help index and all
you'll get is manual connection to the internet). TBUDL *is* the TB
help file. See anything below about active or manual only filtering?
Sorting Office is implemented in The Bat! for auto-classification
of incoming, outgoing, read and replied mail. Each of the above
mentioned message flows can be sorted by folder, accordingly to
its set of rules.
Each rule is determined by its name, the source folder (for
incoming mail it is always Inbox, for outgoing - Outbox and this
cannot be changed), the target folder, sets of signal strings and
defined actions. To create a new rule, open “Account | Sorting
Office/Filters” dialogue, select the desired rule set (depending
on what type of messages you want to classify) in the tree, and
press New button.
Related topics:
Signal strings
Filtering actions
Using special syntax in signal strings
Using The Bat! as a Maling List Server
That's it. Check out the related topics if you like, but nothing's
there on this point.
PF> I suppose this is done to allow users to activate and deactivate
PF> filters that they wish to apply manually.
We are left to suppose, that's for sure. But nothing indicates the
following:
PF> All filters must have the "Active" option checked to work.
That is exactly the point. From there they can be either automatic or
manual only.
PF> The "Manual filters only" option on the re-filter dialog is intended
PF> only to give you the option of applying only those filters that you have
PF> designated as "Manual only".
Meaning that they don't get activated *until* *you* activate them.
This problem could have been avoided simply by making the manual only
option contingent on selecting active first, a very common button
implementation (it would be grayed out until selecting active).
>> 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.
PF> Right, thus the option on the re-filter dialog for "Manual filters
PF> only". Re-filtering without checking that option will invoke all active
PF> filters, regardless of whether or not the "Manual only" option is
PF> checked for the filter.
The funky part is that the re-filtering menu asks for this, uselessly.
PF> So, what you have is:
PF> Active, Manual Only not checked - operate automatically when triggered
PF> by event OR operate on re-filtering if "Manual filters only" is not
PF> selected.
Correct.
PF> Active, Manual Only checked - operate only on re-filtering. If "Manual
PF> filters only" is selected on re-filtering only these filters will be
PF> invoked.
That's the whole ball of wax.
PF> Filters that are not marked "Active" are deactivated regardless of
PF> whether or not "Manual only" is checked.
They are there to use if and when they're changed to active status.
But none if this is explained anywhere. You yourself are just
discovering these details.
>> I don't find a consistent logic here.
PF> There is a logic there once you discover it. It doesn't seem
PF> counterintuitive to me that, for example, a filter has to be active to
PF> work.
Right, there's a logic to it. The point is that it's a totally
undocumented logic, which isn't very logical in itself when you
consider that there's a universe of logical patterns that could be
implemented for a given purpose. There is generally no one way of
doing *anything*. But the logic chosen, whatever it is, should be
specified. Call it what it is. Why be a party to an absence? TB needs
a decent help file, but between TBUDL, fiddling around oneself and
even resorting to the developers once in a while, the show will go on.
>> 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").
PF> This was an error on my part, going back to earlier versions of TB.
PF> Incoming Mail filters do, in fact, operate on _all_ messages in the
PF> InBox when using re-filtering. Sorry to add to the confusion.
Your intentions were good. And that's what I mean about logic. There
are a lot of ways to look at anything. When developing anything
(software or otherwise) the important thing is to analyze the
situation (determine options), set priorities, chart the most all
inclusive and elegant course you can and then stick to it. But you've
got to explain it, or some one else will have to, for you. (Hence
TBUDL).
>> [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.
PF> All conditions placed in the same rule are AND conditions, with one
PF> exception.
What you call "conditions", I would call a "sets of strings". But
that's neither here not there.
PF> An OR condition can be created by using a | between strings
PF> in the same condition, for example, TBUDL|TBBETA can be used to filter
PF> messages from either source to a single folder. I believe the | can only
PF> be used for two strings, however. (I haven't tested it lately.) More
PF> than two OR conditions requires going to the Alternatives.
In that case, it might take a set of string sets in the same rule.
>> 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.
PF> There is nothing in the Help file about this recently added feature and
PF> no one here is sure how to use it, but you don't really need it for most
PF> filtering you normally want to do.
How do you know if you don't know what it does? You are being
protective, perhaps.
>> , although there *is* something on "Special syntax", "used for
>> signal strings", which I assume is what that refers to.
PF> No, this doesn't refer to Regular Expression. It refers to syntax that
PF> may used in conditions in any case.
Are you sure? What's a Regular Expression, then?
>> You mean that it doesn't have to the outbox? Also, do *all* outgoing
>> messages from a given account go *through* the outbox?
PF> I believe that Outgoing Mail filters work on all messages sent. All
PF> messages being sent may actually go through the Outbox. I've never
PF> really noticed.
It has to be assumed they do, if the following quote from the help
file is true:
"the source folder (for incoming mail it is always Inbox, for
outgoing - Outbox and this cannot be changed)"
>> 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...
PF> TB is a very good program once you discover what's under the hood, but
PF> that does take some effort. The developers are aware that the Help file
PF> is now out of date and not complete or understandable enough in many
PF> areas. A new Help file is supposedly in the works for version 2. This
PF> list remains the best source for discovering the potential of the
PF> program, which is amazing in some respects. However, people's needs vary
PF> and it is not necessarily the best program for everyone. I use it
PF> primarily because I produce alot of stock replies and form messages and
PF> TB is the best program around for doing that, but I still much prefer
PF> the way my last mailer handled filtering.
I've used a lot of other email clients and I am 100% committed to TB.
I love a lot of the way it works, above all in composition. The
multiple language spell checking is the best I've ever seen, neither
overly intrusive (it let's you keep working but *does* let you notice
the error), nor requiring special activation (except for changing
languages), and it was so easy to indent the block quotes just done,
as well as adjust line ends. It's practically a word processor, and
don't really mind the lack of band width hogging rich text support,
although I *would* use it for highlighting *received* mail.
I am not about to trade in TB for Eudora, Pegasus, PM Mail or
Lingomail etc., but I am *not* that complacent a person and believe
that a spade should be called a spade. I understand perfectly that
writing code and writing a help file are two different processes with
two different skills called for, and that the programming staff, as
capable and dedicated as it is, is also relatively young (also
likable).
And I am aware the the international language support (which includes
English as a *foreign* language, which I have taught - but then
English was my first language), is much harder for those not totally
immersed in the language in question.
When you have a program that's as powerful as this one, with a built
in commitment to get down to the roots of things, it's going to
attract users who share that vision, that commitment, and this helps
make things more consistent, more congruent, which is as things should
be. Constructive criticism is both positive and necessary. We have to
help the developers be aware of the issues, and these are real issues.
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 a lot of other unread messages.
>> That is exactly right.
PF> You can do this to the extent that you don't want to filter the messages
PF> from the InBox incrementally.
Unfortunately, I do. And this is logical, since I *don't* want to go
around looking into all my accounts and folders to see what came in,
or even remember be how many messages were in each one before the last
mail download. Nor am I going to be able to read all the mail in those
boxes, or even want to.
So the boxes are *always* going to show unread mail in them, which I
can either weed out as I go by filtering incrementally or by doing it
manually, which was done more easily with my last email client, since
mail from all accounts was viewed and sorted by the column selected
(date, account, subject, sender etc.). TB v. 2 is what may save the
day in this regard.
If it was possible to set the ticker for just arrived messages, and
the ticker showed the folder the message was in, this would be less
necessary. I could filter more things automatically. Also, while the
ticker can be turned on with a keystroke set, to turn it off you have
to go into a menu.
PF> You can filter messages incrementally, but I think you would need
PF> to go into the filter properties and make each filter active in
PF> turn, then set them all back to inactive. Hard to say without
PF> actually seeing the messages.
You are right as things stand, but this also implies a need for an
accessible filter manager that doesn't require this "on then off"
scenario, and the implementation of this should contemplate from the
start, that the filters are going to be used either globally or
individually.
>> Regarding the ticker in relation to filtering:
PF> I don't use the ticker.
That is understandable, in terms of the present implementation. But
the concept is good, and could b useful if taken further.
>>>> 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 ...
PF> This issue has been discussed extensively on the list. It is my
PF> understanding also that some sort of flagging features will be in
PF> version 2.
Even Netscape Messenger lets you both flag and establish a 5 tiered
priority.
>> 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.
PF> Park is not a good substitute for flagging;
Do I have an alternative choice at present? I'll just have move the
flagged (parked) messages *first* by sorting on the parked flag, and
moving them to their elite new folder, before moving the rest.
PF> however, parked messages will not be filtered, so that can help.
Nowhere was it stated that I would lose my parked flags on moving
those messages. All it does is ask if I want to move parked messages.
To me this shows a glaring lack of consciousness and made me lose a
lot of work spent selecting a few good messages for follow up within a
sea of mostly junk. I will *never* be able to go back over them.
PF> The only alternative currently in TB is to use folders. CTRL-V
PF> makes it pretty easy to move messages to folders as you go along
PF> through a long list of messages.
Too slow. I want to flag and move on. Moving them comes later, when
I've accumulated enough to do a group of them together, and when I
have time.
>> 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.
PF> I would be so bold as to suggest that if you have that many messages
PF> stored in your InBox that you consider filtering these directly to
PF> folders, then moving or filtering them from there. For example, create a
PF> set of top level folders to handle new messages.
As it stands, different stuff comes to different accounts. Most of it
I can even remember. What I really want is to see it all in one place,
to begin with, but with the account info intact.
PF> When you have time to look at them, select the ones you want to
PF> reply to or are more interested in for whatever reason, do CTRL-V
PF> and move them to a subfolder, e.g. Important. Then Select All the
PF> remainder and move them to another folder, e.g. Old.
I appreciate your taking the time and making the effort to walk
through all this with me, but I am still a bit loathe to do what you
suggest above, so repetitively. I want to flag and the flags will
come, hopefully soon. *Then* I will do as you suggest, if I don't do
something similar to what Alex described and manage to get it done
automatically, or on command, incrementally. What do you think about
having filters implemented for user set flags? That's a damn good
idea, even if I had to think of it and say so myself.
PF> Many things can be accomplished with TB once you start thinking
PF> like it does. :)
OK, but I also want it (and the developers) to think like I do. (You
and I are coming at this from a somewhat different genetic perspective
here, in terms of x's & y's - and no offense meant - after all, I'm
part x myself, and some of my favorite people are totally x people).
The important thing is to map out the total range of possibilities and
develop a strategy of use that's as appropriate as possible to both
TB's underlying design philosophy (which I feel I can and do identify
with) and the way I want to implement that. And I don't feel like that
passive an element.
I would like it if the way in was a little better marked, but this
groups really makes a difference in that respect. It should also make
a difference in terms of where TB is headed (otherwise, it *isn't*
headed - but I don't think that's the case). The way out *has* be
marked by the most underlying and consistent strategies that mesh with
the original motivation, which we probably all share wi each other and
with the developers, to a greater or lesser degree.
PF> And, people on the list have lots of good tips
PF> and tricks.
There's a very good level of high quality interchange going on here.
The internet really is helping to change the world to be what it
should be.
It is going to be hard to answer the rest of the posts I had opened
after this, but that's fine.
Best regards,
Douglas
[EMAIL PROTECTED]
--
--------------------------------------------------------------
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]>
--------------------------------------------------------------
