On Tue, 22 Nov 2005 00:31:57 +1300, Alexey Feldgendler
On Mon, 21 Nov 2005 17:20:56 +0600, Richard Grevers
That's only one step: attach a tag. Various ways of doing this in GUI
can be implemented, including possibly the visual concept of dragging
into container. And exactly the same amount of data storage -- one
"many to many" relation (it doesn't matter whether it's "folder <->
message" or "tag <-> message".
Then you would have to tag all the messages in the query view that you
want them to be grouped with but whose query they don't match, and you
end up with not-quite doubled up information (unless you delete the
query view) - but as you say that tags should not be settable via
rules, you would forever have to manually maintain that tagging as new
messages match the query.
I see now. Yes, that's quite true. You have to choose only one of the
1. Manual addition and deletion of messages to and from folders (the
core procmail way ability).
2. Instant updation of the folder view when its conditions have been
changed (the core gmail way ability).
You can't have them both, it's just logically impossible.
Interesting choice of word, given that it works and works well. Actually,
you forgot an entire class:
3) Update of the view based on statistical probabalistic rules, learning
from the user's manual deletions and additions. (Shall we call this the
mailwasher approach?) Opera does that, too. Note that most Bayesian
systems allow you to augment rules via an explicit whitelist/blacklist.
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/