Re: Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Mon, Jan 22, 2001 at 03:53:44PM +, Dave Pearson wrote: On Mon, Jan 22, 2001 at 04:16:25PM +0100, Heinrich Langos wrote: Dave, you may stop reading. The rest will only bother you and further waste your time. With an attitude like that it's not surprising that you're confused about what I've been saying. Read what I've actually said, look for the reasonable reason this time, then you might find that I've said nothing against the idea of providing the feature you'd like to see. Well, then I'm sorry. I guess I took your repating of "the docs are right" the wrong way. I was not trying to convince you that the docs are wrong and I took your insiting on the thier correctnes as conviction that there is nothing to improve. That really upset me. Sorry, once again. ok ok .. just wanted to make sure we talk about the same thing. i guess most users don't have huge mailboxes since mbox-hooks are a such a nice way to move older mail out of mailboxes after some time. anyway... But we can't actually make such a guess can we? You also seem to be under the impression that I don't archive older mail. I do. Arguing that "most users" do what you'd like them to do doesn't detract from the point that there can and will be large mailboxes defined by the mailbox command. When designing new features it makes sense to work to the extreme case, not the average case (especially when you can't really know what the average is). I was just under the impression that incoming mailboxes usually are small. Though my choice of words may have been inappropriate and insulting. I admit that arguing for "most users" in the absents of statistic data is, well, arguable. :-) In order to deal with extremly big mailboxes I proposed that "jump to the previously know end" strategy. But dealing with large amounts of incoming mail could be a problem. Any ideas? I mean other than limiting the amount to scan like "max_growth_to_scan_for_new_mail=200k" If a mailbox had grown more than 200k since the last scan you would only mark the previously known amount of new mail with a "+" and postpone exact scanning and updating of numbers till the user entered that folder and you had to scan it anyway. jump to the previously know end of the file and scan how may new mails arrived. that shouldn't be too much of a burden for a system. since mails usually don't arrive in large batches. (i know, fetchmail users will hate me.) I don't use fetchmail but the above still isn't true. email does arrive in large batches for me. How comes? Are these large batches usually source initiated (like moderated mailinglists) or are they collected at another MX host before they get transfered to your mail server? In other words: Will they affect all/many of your mailboxes or usually just one ore two? to prevent errors due to other programms, maliciously changing your mailboxes and increasing its size, you could check for that. depending on your level of paranoia you could do anything. from A) checking if a new mail starts exactly where it is supposed to start (at the previously know file-end, which you do anyway by starting parsingthere) That sounds like a good solution for the problem I highlight above. I hope it is. It would save a lot of trouble. PS: You still appear to have a configuration problem with your copy of mutt: , | Mail-Followup-To: heinrich, [EMAIL PROTECTED] ` yeap .. unfortunatly i don't know how to review the headers before sending an email. could it be a problem with the local sendmail configuration? i've got these in my muttrc but it doesnt realy help. - set edit_hdrs ignore * unignorefrom: subject to cc mail-followup-to \ date x-mailer x-url - furthermore i've got "[EMAIL PROTECTED]" on my "lists". but not on "subscribe" since i like to see the sender instead of the list address in the index. if putting it on "subscribe" will solve the "Mail-Followup-To:"-problem i will do that and change index_format accordingly. TIA -heinrich
Re: Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Tue, Jan 23, 2001 at 11:30:57AM +0100, Heinrich Langos wrote:
On Mon, Jan 22, 2001 at 03:53:44PM +, Dave Pearson wrote:
With an attitude like that it's not surprising that you're confused
about what I've been saying. Read what I've actually said, look for the
reasonable reason this time, then you might find that I've said nothing
against the idea of providing the feature you'd like to see.
Well, then I'm sorry. I guess I took your repating of "the docs are right"
the wrong way. I was not trying to convince you that the docs are wrong
and I took your insiting on the thier correctnes as conviction that there
is nothing to improve.
I think I see the problem and the source of the misunderstanding. I wasn't
saying that the documentation was correct, I was saying that the "new mail"
detection *was* reliable within the limits of it's reported abilities. While
I don't have a problem with those limits (I've configured my backup utility,
for example, to preserve time stamps) it doesn't follow that I think that
development should stop right there.
In order to deal with extremly big mailboxes I proposed that "jump to
the previously know end" strategy. But dealing with large amounts of
incoming mail could be a problem.
Any ideas? I mean other than limiting the amount to scan like
"max_growth_to_scan_for_new_mail=200k"
If a mailbox had grown more than 200k since the last scan you would
only mark the previously known amount of new mail with a "+" and
postpone exact scanning and updating of numbers till the user entered
that folder and you had to scan it anyway.
That would seem like an obvious solution. However, I suspect you're starting
to get into design problems that have caused the mutt developers to dismiss
extending this before. The point being that you still end up with a "it
sometimes works, but not always" solution.
In other words you still get something that is "unreliable" for certain
values of "unreliable".
I don't use fetchmail but the above still isn't true. email does arrive
in large batches for me.
How comes?
I'm on a dialup connection. Mail only flows into my box when I dial into my
ISP URL:http://www.demon.net/.
Are these large batches usually source initiated (like
moderated mailinglists) or are they collected at another MX host before
they get transfered to your mail server? In other words: Will they affect
all/many of your mailboxes or usually just one ore two?
They affect all mailboxes.
,
| Mail-Followup-To: heinrich, [EMAIL PROTECTED]
`
yeap .. unfortunatly i don't know how to review the headers before sending
an email.
could it be a problem with the local sendmail configuration?
I think it's more likely you've got a mutt configuration problem.
furthermore i've got "[EMAIL PROTECTED]" on my "lists". but not on
"subscribe" since i like to see the sender instead of the list address in
the index. if putting it on "subscribe" will solve the
"Mail-Followup-To:"-problem i will do that and change index_format
accordingly.
This seems to be your problem. The mutt list should be in your `subscribe'
list, not your `list' list. If the `index_format' isn't what you'd like it
to be that's what you should change.
Here's the index format I use for mailing lists:
,
| # This is the index format for mailing lists.
| set index_format="%4C %Z %{%b %d} %-15.15n (%4l) %s"
`
You can see the whole of my ~/.muttrc setup on my web site. I'm not
suggesting it's actually useful but the list/non-list handling that I have
might give you some ideas.
--
Dave Pearson: | mutt.octet.filter - autoview octet-streams
http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards
Mutt: | muttrc2html - muttrc - HTML utility
http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: Default mailbox display?
On Mon, Jan 22, 2001 at 12:37:09AM +0100, Axel Bichler wrote: Hi Dave! that's more constructive than a self-confessed "uppish tone". It would seem you've decided to do that so I don't really see a problem or a need for such a tone. On the other hand, meticulously insisting on an "It does what it says" point of view could be perceived as an "uppish tone", too. Then your perception would be wrong. I was simply pointing out that the current method wasn't unreliable because it did exactly what it says it does. Moreover, it's never given me any problems. IOW, I was reporting my experiences with it. I see no problem with that. I see nothing uppish about that either. I reported a fact and an experience. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: Default mailbox display? [partially solved]
first for the important part:
while reading the source to find a place to put Brandon Long's "folder
count" patch. i've found a configure switch named "--enable-buffy-size"
that seems to solve the detection issue. i only browsed through the
source since it was quite late, but it seems to read the end of the
mbox to find out if the last message is a new one. so it partially
scans the mbox file. i guess i can extend that to a full scan to
report real numbers.
but at least it partially solves the detection issue.
On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote:
On Sun, Jan 21, 2001 at 06:44:54PM +0100, Heinrich Langos wrote:
On Sun, Jan 21, 2001 at 03:59:22PM +, Dave Pearson wrote:
[...]
Saving such information won't help you work out how many new mails there
are, or if there is new mail at all. It would let you know if the
mailbox had been modified in some way, which is pretty much what mutt
does right now.
nope ... right now mutt only shows that the mailbox has been accessed. not
if it has been modified.
It would appear that we have different definitions of "accessed" and
"modified". My copy of mutt shows me when an mbox has been modified, not
when it has been accessed.
do me a favor and check your "mutt -v" output. if it says
"+BUFFY_SIZE" than your mutt is not just checking access times but
much more than that. if it says "-BUFFY_SIZE" (like mine did) and
after grep-ing your mailbox still shows an "N", i don't get it.
grep doesn't modify your mbox.
so says strace:
open("/var/spool/mail/heinrich", O_RDONLY|0x8000) = 3
(though i have to admit i didn't find out what the 0x8000 part means
in a quick look at /usr/include/*)
BTW: is your mutt running 24/7 or do you start it anew in the morning
like i do... ( and several times a day whenever i've found a new
feature in mutt that i would like to try out ? :) )
right now a simple grep will screw up new mail detection.
try this:
$ echo blah | mail yourself@localhost
$ grep something /var/spool/mail/yourself
$ mutt -y
and you see no "N" ... pretty sad, isn't it?
No, I don't find it sad, I find it consistent with the documentation.
consistent? yes! i admit it is
consistent with a documentation that says: in some cases new mail
detection is not working as one would expect, because there is evil in
world and "Something is rotten in the state of Denmark" :-)
Obviously you're more than happy to find it an itch worth scratching, feel
free to scratch it. All I've been saying is that it *is* reliable, it does
exactly what it says it does. That it doesn't do what you'd like is a
different matter, I'm not commenting on that.
it's not only me who wants mutt to behave that way, i guess.
if it was not the intention to make mutt detect new mail it would say
"... the main menu status bar displays how any of these folders have
been modified since they where accessed by some programm." ;-)
i'm not saying that mutt should constantly scan the whole mailboxes or
anything like that. i just say it could do so on request. or on startup.
The problem with such a scan is that it could take ages. I've got a lot of
mailboxes, some of which can be huge.
it only scans mailboxes that are marked as incoming mailboxes.
so it would do the same thing it does, when opening that mbox. only to
all of them at once... ok ok .. that would be some overhead.
but it will not scan all your mailboxes. especially not those archive
like things where you keep several years of the kernel developers list
or bugtraq :-)
if you keep your incoming mboxes down to a month back or two, it
shouldn't be such a problem. and the results of scanning can be cached
(just in memory or in a status file) and only refreshed if the file
was modified.
with _you_ chosing your favorite or most reliable way you see fit to
detect modification. be it access/modification time, file size
or md5sum.
any volunteers to go for it? i have to finish a studies project before
i can go for more than a quick'n'dirty hack.
-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|
~
Re: Default mailbox display? [partially solved]
On Mon, Jan 22, 2001 at 01:34:03PM +0100, Heinrich Langos wrote: On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote: It would appear that we have different definitions of "accessed" and "modified". My copy of mutt shows me when an mbox has been modified, not when it has been accessed. do me a favor and check your "mutt -v" output. if it says "+BUFFY_SIZE" than your mutt is not just checking access times but much more than that. if it says "-BUFFY_SIZE" (like mine did) and after grep-ing your mailbox still shows an "N", i don't get it. I don't use the buffy feature. Neither have I ever said that an external access of a given mailbox won't cause mutt to fail to show the "N". I keep saying that it works as documented. BTW: is your mutt running 24/7 or do you start it anew in the morning like i do... ( and several times a day whenever i've found a new feature in mutt that i would like to try out ? :) ) 24/7. I also run other instances of mutt on an ad-hoc basis. it's not only me who wants mutt to behave that way, i guess. if it was not the intention to make mutt detect new mail it would say "... the main menu status bar displays how any of these folders have been modified since they where accessed by some programm." ;-) I agree that this can be viewed as a documentation problem. The problem with such a scan is that it could take ages. I've got a lot of mailboxes, some of which can be huge. it only scans mailboxes that are marked as incoming mailboxes. That's why I said "mailboxes". so it would do the same thing it does, when opening that mbox. only to all of them at once... ok ok .. that would be some overhead. That could and would be a *lot* of overhead. but it will not scan all your mailboxes. especially not those archive like things where you keep several years of the kernel developers list or bugtraq :-) I said "mailboxes", not archives. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Mon, Jan 22, 2001 at 01:10:46PM +, Dave Pearson wrote: On Mon, Jan 22, 2001 at 01:34:03PM +0100, Heinrich Langos wrote: On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote: [...] it's not only me who wants mutt to behave that way, i guess. if it was not the intention to make mutt detect new mail it would say "... the main menu status bar displays how any of these folders have been modified since they where accessed by some programm." ;-) I agree that this can be viewed as a documentation problem. In your opinion the documentation is wrong and should be changed to something like the above? Well, ok then I really misunderstood you all the time and I misunderstood the documentation. I'm sorry I wasted your time. I guess continuing this discussion will not get us anywhere then. Anyway I will continue this mail since I have some ideas that may improve the performance in case somebody, maybe me, wants to fix the non-existing problem :-) Dave, you may stop reading. The rest will only bother you and further waste your time. The problem with such a scan is that it could take ages. I've got a lot of mailboxes, some of which can be huge. it only scans mailboxes that are marked as incoming mailboxes. That's why I said "mailboxes". ok ok .. just wanted to make sure we talk about the same thing. i guess most users don't have huge mailboxes since mbox-hooks are a such a nice way to move older mail out of mailboxes after some time. anyway... so it would do the same thing it does, when opening that mbox. only to all of them at once... ok ok .. that would be some overhead. That could and would be a *lot* of overhead. realy? lets see... and keep in mind that this does not need to be mutts standard way to detect new mail. just the one it uses when you TAB TAB. or start mutt with -y. when you save modification date, filesize, known amount of new mail, and an md5sum they will only be generated once for each mailbox. so assuming that you don't add mailboxes on an hourly base I will forget about that one-time load. if a change occures (detecting may be done by modification time, filesize, md5sum (sorted accending by paranoia)) and the filesize increases you could assume that there is new mail (if it decreased you could mark that mailbox as "C" for changed or something like that and stop here). jump to the previously know end of the file and scan how may new mails arrived. that shouldn't be too much of a burden for a system. since mails usually don't arrive in large batches. (i know, fetchmail users will hate me.) to prevent errors due to other programms, maliciously changing your mailboxes and increasing its size, you could check for that. depending on your level of paranoia you could do anything. from A) checking if a new mail starts exactly where it is supposed to start (at the previously know file-end, which you do anyway by starting parsingthere) to Z) checksumming the mailbox up to the last known fileend and comparing with the saved checksum. assuming that increased size usually means that new mail has been added the overhead would be very small. if you still think it is too much overhead go for this one: cache the information that you gathered during those scans to skip the initial scan that mutt does when you enter a folder. this will reduce the overhead to almost zero. only if you don't read the folder that has new mail you will have wasted time. but why do you get that mail at all if you dont read it ? :-) for maildir environments the solution seems straightforward. what about imap? i don't have a clue. could somebody enlighten me? -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| ~
Re: Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Mon, Jan 22, 2001 at 04:16:25PM +0100, Heinrich Langos wrote: Dave, you may stop reading. The rest will only bother you and further waste your time. With an attitude like that it's not surprising that you're confused about what I've been saying. Read what I've actually said, look for the reasonable reason this time, then you might find that I've said nothing against the idea of providing the feature you'd like to see. IOW, try being less insulting and use a little more comprehension. That's why I said "mailboxes". ok ok .. just wanted to make sure we talk about the same thing. i guess most users don't have huge mailboxes since mbox-hooks are a such a nice way to move older mail out of mailboxes after some time. anyway... But we can't actually make such a guess can we? You also seem to be under the impression that I don't archive older mail. I do. Arguing that "most users" do what you'd like them to do doesn't detract from the point that there can and will be large mailboxes defined by the mailbox command. When designing new features it makes sense to work to the extreme case, not the average case (especially when you can't really know what the average is). if a change occures (detecting may be done by modification time, filesize, md5sum (sorted accending by paranoia)) and the filesize increases you could assume that there is new mail (if it decreased you could mark that mailbox as "C" for changed or something like that and stop here). Note that an increase in size might be a reduction in the number of actual emails. I might have deleted a load but saved one large email from somewhere else to the mailbox in question. IOW, an increase in size can't be assumed to be new mail. jump to the previously know end of the file and scan how may new mails arrived. that shouldn't be too much of a burden for a system. since mails usually don't arrive in large batches. (i know, fetchmail users will hate me.) I don't use fetchmail but the above still isn't true. email does arrive in large batches for me. to prevent errors due to other programms, maliciously changing your mailboxes and increasing its size, you could check for that. depending on your level of paranoia you could do anything. from A) checking if a new mail starts exactly where it is supposed to start (at the previously know file-end, which you do anyway by starting parsingthere) That sounds like a good solution for the problem I highlight above. PS: You still appear to have a configuration problem with your copy of mutt: , | Mail-Followup-To: heinrich, [EMAIL PROTECTED] ` -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: Default mailbox display?
Daniel -- ...and then Daniel Freedman said... % % My mutt is now at 1.0.1i, and I'll try to convince the sysadmin to % upgrade to 1.25. Could this version difference affect my not seeing Well, you could always grab the source and build it yourself; the only special program is mutt_dotlock, and I believe that was around for 1.0... % new mail marked, or maybe it's still present in the current release? % Am i correct to guess AFS? Any other suggestions are much % appreciated. I dunno from AFS; sorry. % % Thanks so much, HTH HAND % % Daniel % :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! PGP signature
Re: Default mailbox display?
On Sun, Jan 21, 2001 at 04:23:53PM +0100, Martin Schweizer wrote: Hello Heinrich On Fri, Jan 19, 2001 at 12:24:40PM +0100 Heinrich Langos wrote: One thing that I think would help not only me, but tons of others is something like this: 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:141478K] Mail/nymip [Msgs:54 368K] The above is nice! But how you do you set the 'index_format=' variable for this view? you can't ... thats what this whole thread is about. ;-) i was just making up something to stirr up those who are content with something that is not good enough. something that could be done better but isn't. -heinrich
Re: Default mailbox display?
On Sat, Jan 20, 2001 at 05:40:03PM +0100, Heinrich Langos wrote: On Fri, Jan 19, 2001 at 12:05:01PM +, Dave Pearson wrote: On Fri, Jan 19, 2001 at 12:24:40PM +0100, Heinrich Langos wrote: the problem with "-y" is that it simply doesn't work reliably. Yes it does. No it doesn't. Been there, tried it. Then your experience is different from mine. I've been using mutt since before the mailboxes feature was added and, apart from the documented issues (which you quoted) it has always worked reliably. That's why I'm saying it does work reliably. The only things I've ever seen that can affect it are those that are documented. We talk about multiple incoming mboxes that are fed by procmail, don't we? Correct. 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. There you go then. The reason that the mailboxes appear to have not been updated since you last read them is because they've not been updated since you last "read" them. I do backups here too and I don't have a problem, that's because I ensure that my backup solution preserves timestamps. 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? The quote is informing you that external processes might change the timestamp behaviour. 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! :-) Please don't suggest that I'm defending a weakness, I'm not. I am pointing out that it does what it says in the documentation. It points out it's own weakness and that other than the documented issues it's reliable. or is there a _reasonable_ opposition against saving status information that i don't see? Saving such information won't help you work out how many new mails there are, or if there is new mail at all. It would let you know if the mailbox had been modified in some way, which is pretty much what mutt does right now. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: Default mailbox display?
On Sun, Jan 21, 2001 at 03:59:22PM +, Dave Pearson wrote: On Sat, Jan 20, 2001 at 05:40:03PM +0100, Heinrich Langos wrote: On Fri, Jan 19, 2001 at 12:05:01PM +, Dave Pearson wrote: On Fri, Jan 19, 2001 at 12:24:40PM +0100, Heinrich Langos wrote: the problem with "-y" is that it simply doesn't work reliably. Yes it does. No it doesn't. Been there, tried it. Then your experience is different from mine. I've been using mutt since before the mailboxes feature was added and, apart from the documented issues (which you quoted) it has always worked reliably. That's why I'm saying it does work reliably. The only things I've ever seen that can affect it are those that are documented. [...] The quote is informing you that external processes might change the timestamp behaviour. leading to non-detection of new mail ... i don't want mutt to tell me if i or some programms have accessed the mailbox. i want it to tell me if there is new mail in there. BTW: pointing your finger at evil software that doesn't conform to standards will not solve the problem. if that was enough, nobody at the samba development team would have to care about yet another microsoft-"extention" of standards. 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! :-) Please don't suggest that I'm defending a weakness, I'm not. I am pointing out that it does what it says in the documentation. It points out it's own weakness and that other than the documented issues it's reliable. sorry, but the documented issues is what i am ranting about and what i proposed a solution for. documenting an issue may be enough for M$ or IBM. working to resolve the documented issue is what open source is about, isn't it? or is there a _reasonable_ opposition against saving status information that i don't see? Saving such information won't help you work out how many new mails there are, or if there is new mail at all. It would let you know if the mailbox had been modified in some way, which is pretty much what mutt does right now. nope ... right now mutt only shows that the mailbox has been accessed. not if it has been modified. right now a simple grep will screw up new mail detection. try this: $ echo blah | mail yourself@localhost $ grep something /var/spool/mail/yourself $ mutt -y and you see no "N" ... pretty sad, isn't it? if mutt would realy show modification i would instantly shut up. i'm not saying that mutt should constantly scan the whole mailboxes or anything like that. i just say it could do so on request. or on startup. but it seems that i am the only one with that problem. so i guess i'll have to roll my own mutt. i guess the code that is needed is already in there... it just needs some tweaking. -heinrich ps: sorry for my uppish tone ... but i have recently had an overdose of "it's free. quit moaning!"-attitude. :) -- 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| ~
Re: Default mailbox display?
Hi Heinrich! On Fri, 19 Jan 2001, Heinrich Langos wrote: how about this ? Mail/mutt-users [Msgs:413 New:18 1.1M] Mail/sf/vuln-dev [Msgs:141478K] Mail/nymip [Msgs:54 368K] now wouldn't that be nice ? There's a patch available on Brandon Long's "mutt insanity" site (linked from mutt.org). quote Folder Count This patch causes mutt to count the number of messages and new messages in a folder when you are using the mutt Folder Mode (dirlist.c). This has a lot of overhead, and is slow (especially over NFS), but if you have cycles to spare, or few mail folders, this is for you. First Version Patched: 0.47 Author: Brandon Long PGP Effects: None /quote The patch is targeted at an older version of mutt (1.0 or so, IIRC), but it shouldn't be too hard to adopt it for a current version. If you try it, I would like to know how it works. Another approach I've seen on one of the linked mutt pages is a script, which uses procmail's log to determine the number of new messages. Regards, Axel
Re: Default mailbox display?
On Fri, Jan 19, 2001, Dave Pearson wrote: Yes it does. 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. Hi, I'd like to follow up this conversation with a concrete question about this new mail detection that has been bothering me for a bit: I've never been able to have mutt inform me of new mail in my mailboxes, which are filtered by procmail after being retreived from the dept. mailhub by fetchmail (even though they're listed properly with the mailbox command in my muttrc). I'm mentioning this as I don't think I'm encountering any of the noted access issues above as I don't grep my mailbox files or otherwise touch them outside mutt and the only backup script that the sysadmin tells us about runs at 5am everyday (and I still can't see new mail at any time of the day). My only guess might be that I'm running on AFS, which doesn't seem to be as extensively tested and I've encountered a few other mail difficulties with AFS. My mutt is now at 1.0.1i, and I'll try to convince the sysadmin to upgrade to 1.25. Could this version difference affect my not seeing new mail marked, or maybe it's still present in the current release? Am i correct to guess AFS? Any other suggestions are much appreciated. Thanks so much, Daniel -- Daniel A. Freedman Laboratory for Atomic and Solid State Physics Department of Physics Cornell University
Re: Default mailbox display?
Hi Dave! On Sun, 21 Jan 2001, Dave Pearson wrote: Obviously the best method of dealing with this is to implement a solution, Ack. But before reinventing something, it seems always advisible to check if there's alreay a solution. Finally, this can be accomplished by a discussing the problem here... that's more constructive than a self-confessed "uppish tone". It would seem you've decided to do that so I don't really see a problem or a need for such a tone. On the other hand, meticulously insisting on an "It does what it says" point of view could be perceived as an "uppish tone", too. I would also like to see the discussed feature, so I'm thinking about my contribution to an appropriate solution. Regards, Axel
Re: Default mailbox display?
On Fri, Jan 19, 2001 at 12:05:01PM +, 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 +, 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:141478K]
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
Re: Default mailbox display?
On Thu, Jan 18, 2001 at 09:01:42PM -0800, Trae McCombs wrote:
One thing that I think would help not only me, but tons of others is
something like this:
mailbox 1 3 new messages
mailbox 2 12 new messages
mailbox 3 8 new messages
Where you had the "status bar" that you could move up and down between
mailboxes... and then you would get into the messages of that mailbox.
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).
If you want mutt to do this on startup you could create an alias or
something or stick this:
,
| push "change-folder?toggle-mailboxes"
`
at the end of your ~/.muttrc.
I'd also think it would be cool to have some sort of key binding that
would allow you to get back out to the main mailbox once deep in another
mailbox so you wouldn't have to quit.
That's what the macro system is for. For example:
,
| macro index "h" "change-folder!\n"
`
choose the key of your choice (in the above "h" (for "home") would be the
key, look at the binding list (help screen) for the section of mutt in
question to see that you won't be overriding a useful binding), also
remember to define the macro for the pager and anywhere else that makes
sense.
Or, perhaps, when you say "main mailbox" you mean the initial display you're
talking about? If so you can use the macro system again. For example:
,
| macro pager "y" "sync-mailboxchange-folder?toggle-mailboxes"
`
with the above in place pressing "y" in the pager would take you back to the
screen you get when you do a "mutt -y".
Sorry I'm such a lamer, especially if this is something easy to fix. If
someone has the time, and can provide a .muttrc to accomplish this, or
better still, what I need to toss into my .muttrc, I would be forever in
your debt. :)
The debt is noted. :
--
Dave Pearson: | mutt.octet.filter - autoview octet-streams
http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards
Mutt: | muttrc2html - muttrc - HTML utility
http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: Default mailbox display?
I also wanted to use my arrow keys to navigate through folders. (like I did in pine.) what I have now is: macro index left "change-folder?" this binds the left key to get you to the change-folder menu, f you are in the message index. (I think you need the mailboxes command to tell mutt which folders you have) also, I did: bind pager left exit this will get me from the pager back to the index. On Thu 2001-01-18, Trae McCombs wrote: Hey gang, Sorry to bug *. I have a question that has long plagued me with using Mutt. I've always had to have everything come to one mailbox, and then simply leave everything in one huge archive. I have procmail setup, and that's great, but I hate having to change into the mailboxes to see if there is anything new in those mailboxes. One thing that I think would help not only me, but tons of others is something like this: mailbox 1 3 new messages mailbox 2 12 new messages mailbox 3 8 new messages Where you had the "status bar" that you could move up and down between mailboxes... and then you would get into the messages of that mailbox. I'd also think it would be cool to have some sort of key binding that would allow you to get back out to the main mailbox once deep in another mailbox so you wouldn't have to quit. Anyhoo... Sorry I'm such a lamer, especially if this is something easy to fix. If someone has the time, and can provide a .muttrc to accomplish this, or better still, what I need to toss into my .muttrc, I would be forever in your debt. :) Yours, Trae -- Trae McCombs | [EMAIL PROTECTED] Community Evangelist 1 888 546 8948 ext. 76900 Founder: Themes.org -- Linux.com http://octobrx.com/ -- Personal page
Re: Default mailbox display?
On Fri, Jan 19, 2001 at 09:27:53AM +, Dave Pearson wrote:
On Thu, Jan 18, 2001 at 09:01:42PM -0800, Trae McCombs wrote:
One thing that I think would help not only me, but tons of others is
something like this:
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:141478K]
Mail/nymip [Msgs:54 368K]
now wouldn't that be nice ?
Where you had the "status bar" that you could move up and down between
mailboxes... and then you would get into the messages of that mailbox.
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.
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.
---
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.
i'm not sure if saving a mail from your main incoming folder to one of
the other folders will reset its access time as well .. havn't tried
yet.
BTW: unread but old mail is not detected that way at all.
i see the problem but i have not yet seen a correct solution to it.
i guess i could hatch one if somebody told me how mutt recognizes new
and unread mail inside a folder. yes i am to damn lazy to read the
source :-)))
-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|
~
Re: Default mailbox display?
On Fri, Jan 19, 2001 at 12:24:40PM +0100, Heinrich Langos wrote:
On Fri, Jan 19, 2001 at 09:27:53AM +, 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:141478K]
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).
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.
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.
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.
--
Dave Pearson: | mutt.octet.filter - autoview octet-streams
http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards
Mutt: | muttrc2html - muttrc - HTML utility
http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: Default mailbox display?
Hi Heinrich, One thing that I think would help not only me, but tons of others is something like this: 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:141478K] Mail/nymip [Msgs:54 368K] now wouldn't that be nice ? This implies that mutt scans all folders with new mail (at least with mbox style folders)to determine the new-mail-count. This could be a huge performance loss at start up. Ciao for now, Dirk -- Dirk Ruediger, Rostock, Germany
Re: Default mailbox display?
Hello Heinrich! On Fri, 19 Jan 2001, Heinrich Langos wrote: On Fri, Jan 19, 2001 at 09:27:53AM +, Dave Pearson wrote: On Thu, Jan 18, 2001 at 09:01:42PM -0800, Trae McCombs wrote: One thing that I think would help not only me, but tons of others is something like this: 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:141478K] Mail/nymip [Msgs:54 368K] now wouldn't that be nice ? What about 'frm Mail/mutt-users' or 'frm Mail/sf/vuln-dev' or 'frm Mail/nymip'? bye - Wilhelm -- MicroSoft "ILOVEYOU". Thanks for engineering a 100% Virus Enabled Platform! (C) by Al Hopper [EMAIL PROTECTED] 2 Jan 2001 on solarisonintel
Default mailbox display?
Hey gang, Sorry to bug *. I have a question that has long plagued me with using Mutt. I've always had to have everything come to one mailbox, and then simply leave everything in one huge archive. I have procmail setup, and that's great, but I hate having to change into the mailboxes to see if there is anything new in those mailboxes. One thing that I think would help not only me, but tons of others is something like this: mailbox 1 3 new messages mailbox 2 12 new messages mailbox 3 8 new messages Where you had the "status bar" that you could move up and down between mailboxes... and then you would get into the messages of that mailbox. I'd also think it would be cool to have some sort of key binding that would allow you to get back out to the main mailbox once deep in another mailbox so you wouldn't have to quit. Anyhoo... Sorry I'm such a lamer, especially if this is something easy to fix. If someone has the time, and can provide a .muttrc to accomplish this, or better still, what I need to toss into my .muttrc, I would be forever in your debt. :) Yours, Trae -- Trae McCombs | [EMAIL PROTECTED] Community Evangelist 1 888 546 8948 ext. 76900 Founder: Themes.org -- Linux.com http://octobrx.com/ -- Personal page
Re: Default mailbox display?
On Thu, Jan 18, 2001 at 09:01:42PM -0800, Trae McCombs wrote: I have procmail setup, and that's great, but I hate having to change into the mailboxes to see if there is anything new in those mailboxes. Maybe I'm not understanding your question, but how about just ctabtabtab That lists your mailboxes and puts an N beside those that have new mail. The 'j' and 'k' keys move the cursor up and down the list and enter puts you into that mailbox. I'd also think it would be cool to have some sort of key binding that would allow you to get back out to the main mailbox once deep in another mailbox so you wouldn't have to quit. c!return HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | RF Communications Product Generation Unit | Spokane, Washington, USA
