At 10:50 PM 7/2/99 -0400, David Thorburn-Gundlach wrote:
>Barbara --
>
>...and then Barbara K Jensen said...
>% Excerpts from mail: 30-Jun-99 Re: installation errors for.. by David
>% [EMAIL PROTECTED]
>% > > 1. When Mutt is started or ended, it insists on doing a message count
>% >
>% > When Mutt is started, it reads your inbox. What on earth would you want
>%
>% I don't want it to fetch all of my messages by default, because with a
>% lot of messages, this takes a lot of time. I just want it to fetch a
>% screenful, or the unread ones, or a few I plan to look at for now, so I
>% can load mutt and start working within a few seconds.
>
>I get the impression that you're using IMAP, and I'm no IMAP expert,
>but it seems to me that mutt has to read the mailbox to know which
>ones are read and which aren't. Now, if you only wanted to get the
>top few in the box, you might be able to get away with not reading the
>whole thing, but even getting just the bottom few will require going
>through them all to get there. Um, right?
Um, no. For purposes of what happens with mutt/IMAP, you can "pretend"
that IMAP is an infinitely fast server talking to your mutt client over
a slow communications link. You can afford for the server to read all
the messages, but you don't want it to send them all to the mutt client.
Server calls exist to retrieve just specific headers, specific messages,
etc., to minimize the data transfer.
(In practice, the server probably doesn't need to read them all either...
the implementations I've seen seem to store one mail body per file, with
one or a small fixed number of files containing a "table of contents" of
the mail in that folder/mailbox.)
>
>%
>% > When Mutt is exited, it records any changes to your mailbox. You do
>% > want your deleted or read messages to be actually removed or marked as
>% > read, don't you?
>%
>% Yes, however, when I don't actually do any reading or deleting, and
>% simply exit without making changes, why does it still need to sort
>% through everything?
>
>If you just exit and make no changes, then try exiting with 'x' instead
>of quitting with 'q'; the former abandons any changes (including any
>status updates it might attempt, like changing new-unread messages
>to old-unread).
The IMAP issues of how to handle this are different... you can't just
go by the standard mailbox view. IMAP has a "logically deleted" flag
that can be stored and left there, with physical deletes commanded to
happen in a later session (and/or the delete flag removed). (Mutt
doesn't currently support this, though pine does.) Possible ways to
do 'q' and 'x' for IMAP have been discussed on one of the mutt lists
(I forget which) but if I recall, no obviously perfect way to handle this
has emerged.
>
>
>%
>% This brings up another complaint with Mutt's exit routine: when I quit
>% Mutt, after the "move read messages" query, Mutt asks if I want to purge
>% deleted messages. This part is in error, however, because what it is
>% really asking is whether it should update the IMAP server with message
>% information. No matter if I answer Y or N, Mutt still expunges messages
>% from the IMAP server. This is only confusing when I answer No, because
>% then previously deleted messages (for example, from another mail client
>% session) DO get expunged, but currently deleted messages (from my
>% current mutt session) simply get undeleted, which I don't want either.
>
>You're definitely out of my league now :-)
She's right though. elm never had the view of logically deleted messages
(expunge is a separate operation; some mail clients also refer to this process
as "compacting" a mailbox) that pine has... and mutt has inherited elm's view
of things, but pine's meshes much better with IMAP capabilities.
My suspicion is that enough mutt developers haven't been exposed to IMAP
yet. I'm not really a mutt developer--time too short--though I follow that
list w/occasional comments; however, I've had IMAP inflicted on me at work,
and this will probably happen to others.
I think mutt will eventually need a full support for IMAP as more and more
companies move away from mbox-type mailboxes for security and reliability
reasons. (Yes, I know some people are working on it; thus I'm more just
emphasizing that this is the Right Thing To Do.)
Cheers,
Stan
