<<< Date Index >>>     <<< Thread Index >>>

Re: Make unread the same as new



On Mon, Oct 13, 2003 at 08:26:11AM -0400, David T-G wrote:
> % The fact is, many mail clients (if not most) do this.  It /is/ a
> 
> Heh.  Many mail clients (if not most) would puke over big messagestores
> that are a breeze for mutt.  Can you imagine Michelle using anything
> else?
> 
> 
> % desireable feature, and one I too have long wished were implemented in
> 
> You'll have to define desireable [sic] for me.  

Easy: a feature that people want.  YOU may not want it, but the
question is asked here fairly often, indicating that it is desireable.

> % mutt.  As for reading through hundreds of megabytes of mail, one would
> % hope that such folders are archive folders, and don't normally receive
> 
> Right, so you might argue that the mailboxes command should only include
> "active" mailboxes which one hopes are small (but that isn't necessarily
> the case, as

I could argue that, but I won't.  Actually, that is how my mailboxes
commands are set up (i.e. archive folders are not included), so such a
feature would be quite welcome by me, since none of the folders mutt
would be checking would be that large...

But still, I would not support that argument.  I acknowledge and
support the idea that others' use of mutt will differ from mine.  I
think that's the whole point of having a powerful, configurable mail
client.

> But that's the point!  You can't use a folder-hook on it until
> you're in it!  You're proposing opening and reading every single
> mailbox just to see the status of its contents simply in order to
> present it for selection!

Well, that's unfortunate, but naively, it would seem there should be
no good reason why folder hooks could not be evaluated immediately
upon the folder name being known.  IOW, you could evalute the hooks
immediately when one is selected, rather than waiting until the folder
has actually been opened.  Is there such a reason?

> % mail to determine the newness or unread-ness of a message if one
> % didn't want to.
> 
> If anything, I'd say that either listed mailboxes do get checked and so
> your archive mailboxes don't get listed or we make a new command which
> lists mailboxes which should have their statuses checked.

Well, again, that would suit me well.  YMMV.

> % There are other reasons not to rely on access times.  For example, if
> % some system process accesses every file on the system, but does not
> 
> Oh, I agree that mtime/atime is very much a kludge.  

Then you're practically admitting that an alternative should be
available.  I think the only /reliable/ alternative involves parsing
each message.  You could, however, cache message information (i.e.
file offsets of each message, start and end of headers, etc.) to make
such things much faster...  I imagine that mutt would benefit greatly
from such a cache in other ways too.

> Unfortunately, you cannot rely on size, and running a checksum is
> just about as slow as parsing the file anyway, so if you want to
> save time you're only left with mtime/atime.

But my point is, many people don't want to save time.  If your mail
folders are small enough, then the time saved might still be
significant (in relative terms), but at the same time not noticable to
the user.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.
Replying to it will result in undeliverable mail.
Sorry for the inconvenience.  Thank the spammers.

Attachment: pgpLTVK7qJ34z.pgp
Description: PGP signature