On Fri, Jan 19, 2001 at 12:05:01PM +0000, Dave Pearson wrote:
> On Fri, Jan 19, 2001 at 12:24:40PM +0100, Heinrich Langos wrote:
> > On Fri, Jan 19, 2001 at 09:27:53AM +0000, Dave Pearson wrote:
> > > On Thu, Jan 18, 2001 at 09:01:42PM -0800, Trae McCombs wrote:
> > >
> > > > mailbox 1 3 new messages
> > > > mailbox 2 12 new messages
> > > > mailbox 3 8 new messages
> >
> > how about this ?
> >
> > Mail/mutt-users [Msgs:413 New:18 1.1M]
> > Mail/sf/vuln-dev [Msgs:141 478K]
> > Mail/nymip [Msgs:54 368K]
> >
> > now wouldn't that be nice ?
>
> Nice, be expensive. Each mailbox would have to be read to get that
> information (at least, that's true for mbox style mailboxes).
sure it is expensive. i didn't say it was cheap. but hey somehow we have to
burn those extra MHz :-)
>
> > > Although it doesn't give you the count you're after it sounds more or less
> > > like you're asking for the screen you'll be presented with if you start mutt
> > > with the "-y" switch ("man mutt" lists all the available switches).
> >
> > the problem with "-y" is that it simply doesn't work reliably.
>
> Yes it does.
No it doesn't. Been there, tried it.
We talk about multiple incoming mboxes that are fed by procmail, don't we?
I can asure you that I often find new mail in these mailboxes eventhough
"mutt -y" doesn't tell so. That may be because wo do backup our system.
And from time to time I allow myself to grep my mail directory for some
phonenumber or other information.
> > to quote the docs:
> > -----------
> > Note: new mail is detected by comparing the last modification time to
> > the last access time. Utilities like biff or frm or any other program
> > which accesses the mailbox might cause Mutt to never detect new mail
> > for that mailbox if they do not properly reset the access time. Backup
> > tools are another common reason for updated access times.
> > -----------
>
> That quote is informing you that if you allow other tools to modify the
> timestamps. It doesn't say that mutt's detection of mailboxes with new mail
> is unreliable.
Yes it does. Or what else does this note say?
1. It states that detection of new mail relies on modification and access time.
2. It further says that there are many utilities that don't handle these times
"right".
3. If you dare to use one of those utilities detection of new mail
will not be reliable.
I didn't say that mutt doesn't detect new mail when it is running.
But it surely doesn't tell you in which mailboxes there is new mail
just by starting mutt -y or doing TAB TAB when changing folders.
There is just to much that could have happend to the timestamps
since it was started last time.
So you have to go and check each mailbox by yourself if you want to be
sure.
>
> > same happens when you change to one of those folders and you quit without
> > saving changes to another folder. if you change into that folder again you
> > will see mails marked as new though the folder was not marked by "N" in
> > the folder menue.
>
> The "N" status of a mailbox tells you that it has been updated since you
> last read the mailbox.
Using the same flag for "new mail" in the index view and
"updated since you last read" in the folder menu is at least confusing.
from the view point of software ergonomics it is a deadly sin.
and to quote the docs again (this is just a few lines above the Note
that i quoted before)...
---------------
Usage: mailboxes [!]filename [ filename ... ]
This command specifies folders which can receive mail and which will
be checked for new messages. By default, the main menu status bar
displays how many of these folders have new messages.
---------------
The "how many have new messages." is the crucial part. This sugessts
that it does check for new mails. Though it only checks for access and
modification times.
Without the Note it would be a lie. With the note it says that it
doesn't achieve it goal (detecting new mail on several mboxes) yet.
But there is room for improvement.
Since it is mutt's only way to have an overview of your incoming
mailboxes i think mutt is actually quite weak here.
allow for one final quote:
"All mail clients suck. This one just sucks less."
So please stop defending mutt's weakness in this area and lets try to
think of a way to improve mutt. I love mutt and I want it to suck even
less! :-)
how about saving for each of the "mailboxes"
-size
-modification time (not the access time)
-and the last known amount of total and unread mails in it
in a status file that is read on start.
for those who like it to be stronger we could save md5sums instead of
size and modification date. md5sum-ing the folder would still be much
faster than scaning the whole folder for new mail by parsing the file.
on start mutt would check if the saved data matches the one it finds
on the disk. it could mark the folder with that nice "N" that have
changed and with an "O" those who had unread mail before but didn't
change. status data for a folder is only saved back to disk when you
sync that mbox.
this would still not show the amount of new mail. but you could at
least show the amount of unread mail. and maybe mark it with a "+" if
there is an unknown amount of new mail in there as well.
like:
Mail/mutt-users [Msgs:413+ Unread:18+ 1.1M+3.5K]
i don't have a clue what this all would mean for other styles of
mailboxes. especialy for imap. so the whole idea could be total
nonsense but if it worked if would be at least more reliable than the
current "solution".
and sure the schema would be messed up if you use another mail tool in
between. same as today. but it would only mark more mail folders "N"
than it should. IMHO that would still be much better than marking less
folders "N" like it currently does.
or is there a _reasonable_ opposition against saving status information
that i don't see?
-heinrich
--
Heinrich Langos <[EMAIL PROTECTED]>
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_________________________________________________________________
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
