On Thu, 2001-12-06 at 14:54, Robert R. Wal wrote:
> You can also give messages weight based on all obnoxious criteria and
> limit, tag, or delete them based on their weight.
Nice! Evolution is pretty deficient at scoring, which I consider to be
a highly desirable feature.
> It can give you pretty much, but obviously you never cared to RTFM ;)
Heh. Actually, I've read the non-reference sections of the manual about
ten times, and dug endlessly through the reference bits. After
reviewing your claims, and browsing the manual (for the Nth time), I've
concluded (1) mutt can probably do most of the things you claim, but (2)
the relevant information is spread out across about six subsections.
Let's try a test.
Ideally, I'd like to search three separate folders for all mail to or
from [EMAIL PROTECTED] or [EMAIL PROTECTED] during September 2000, display all
matching messages in a list view, and then search *those* for a number
of different strings in the body. Bonus points if I can save the query
or have it automatically update if new, matching mail arrives. (This is
a real test case from a recent problem I had.)
How much of this can I actually do in mutt? Hacks and workarounds are
OK, but I'd like to know the (1) limitations and (2) actual keystrokes
so I can try it before posting my apology.
[A bit of UI criticism: The main mutt UI is very good (it even includes
a menu bar of all important commands for novice users!), but these
extended features lack "discoverability"--they can't be figured out
simply by screwing around with the program. A HOWTO would have been
very helpful.]
> As for mailbox scan time, not much can be done to provide corruptless
> mboxes and fast scan time :( Whenever anything changes in the file
> (indicated by filetimes in the inode) MUA has to scan the whole file,
> since the changes need not to be limited to appending. You can make
> assumtion that ``nothing except me can change the content of the mbox
> otherwise than appending to it'', but then there is nothing but prayer
> to prevent you from loosing mail.
jwz managed to do a pretty good job with summary files in Communicator
until later maintainers screwed it up. There's a bunch of tricks you
can use:
1) Store secure hashes of each message in your index file.
2) Before displaying a message, double-check the alleged message
boundaries and the hash code.
3) Before editing any portion of the mbox, check the hashes of
all affected messages.
This means that the list view can get arbitrarily inaccurate in
pathological cases, but the mail client will detect it before any damage
occurs.
> PS. To others: will change of mailbox format from mbox to Maildir
> improve scan time?
It may kill your OS--most Unices get grumpy about massive directory
listings, and as previously discussed, my mail folders are pretty rude.
AFAIK, maildir also requires one full disk block per file (unless you're
using ReiserFS).
Cheers,
Eric
