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

Re: Make unread the same as new



Derek, et al --

...and then Derek Martin said...
% 
% On Sun, Oct 12, 2003 at 09:44:11PM -0400, David T-G wrote:
% > 
% > Nope.  Imagine how long it would take to go through a few hundred
% > megabytes of mail folder just to tell you how many messages are in there
% > every time you wanted to look at a folder list.
% 
% 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.  I for one have no interest
whatsoever in adding that code to mutt (yes, even with the kitchen sink
collection of patches that I have!) or in taking the time for it to run.


% 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

  bash-2.05a$ ls -1s Mail/F.* |sort -n | tail
   17088 Mail/F.suse-linux-e
   17432 Mail/F.vim
   17744 Mail/F.perl-beginners
   22520 Mail/F.mysql
   22648 Mail/F.qmail
   26736 Mail/F.HTMLFluffStuff
   31288 Mail/F.openoffice
   39160 Mail/F.php
   52312 Mail/F.cygwin
   70000 Mail/F.spamassassin

shows -- even after a housecleaning to archive older content!), in which
case it would be a much more reasonable "feature".


% new mail.  If this were a configurable option which could be set by a
% folder-hook, one need never have mutt read hundreds of megabytes of

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!


% 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.


% 
% 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.  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.


% take care to reset the atime, mutt will not notice new mail if it was
% received before that process runs.  Something on my mail server does
% this; it is quite annoying.  It may have been updatedb which I have
% disabled recently, but I can't be sure just yet...

That really sucks, and I feel for you.  I hope you find what is mucking
with your files -- and that you can then fix the problem (if you were
under some backup programs you'd be SOL).  But that's obviously some
problem which, in a perfect world, shouldn't be, and outside of mutt.
Yes, we should be expansive with what we accept, and that should extend
to ALL interaction, but sometimes it isn't worth it.


% 
% Sometimes, slow and reliable /is/ what you want.

Admitted.  Sometimes it isn't, though.


% 
% -- 
% Derek D. Martin


HTH & HAND

:-D
-- 
David T-G                      * There is too much animal courage in 
(play) davidtg@xxxxxxxxxxxxxxx * society and not sufficient moral courage.
(work) davidtgwork@xxxxxxxxxxxxxxx  -- Mary Baker Eddy, "Science and Health"
http://justpickone.org/davidtg/      Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

Attachment: pgpnVyCvfiYAj.pgp
Description: PGP signature