Re: Two alternative proposed fixes [Was: Re: A wish for the mailboxes command]
On Fri, Jun 25, 2010 at 02:46:23PM +0200, Michael Ludwig wrote: > Checking for new mail before a user-triggered write operation, as you > suggested, would, I think, fix the issue. Thank you. After checking 114 fleas which mentioned "New mail", I've added ticket #3424. Erik -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw
Re: Two alternative proposed fixes [Was: Re: A wish for the mailboxes command]
Erik Christiansen schrieb am 25.06.2010 um 20:48 (+1000): > While that would be a lot of fun, mutt itself does seem able to be > cured of its current fibbing behaviour. (Try copying this message to > this mail folder. Mutt says "New mail in this mailbox." What hokum.) Confirmed :-) > Mutt needs to check the size and/or atime of the destination folder > _before_ it writes, rather than cookily doing it _after_. Then the > erroneous and misleading immediate message would go away. > > To fix the problem of mutt adding the transfer recipient folder to its > list of "New" folders on its next scan, another small bugfix is also > required. Once the recipient file has been written, mutt needs to > update its current values for file size and atime, so that the > "Newness" reference will be correct. > > Would that not put an end to its fibbing ways? Sounds like it would! One more example, I have the following setting to store mail conversations as threads: set spoolfile = +Neu # c! set record = +Neu # c< So when I send a message that is not going to a list, it goes to +Neu, and I'm notified of a new message in +Neu, which is technically correct, but as I put it there myself I don't need to be told about it. Checking for new mail before a user-triggered write operation, as you suggested, would, I think, fix the issue. -- Michael Ludwig
Two alternative proposed fixes [Was: Re: A wish for the mailboxes command]
On Fri, Jun 25, 2010 at 10:47:29AM +0100, Chris G wrote: > I don't really want to know when new mail arrives, what I want is the > ability to quickly go to all the mailboxes which have new incoming > mail when I'm running mutt. I don't have any need to respond quickly > to messages, just a need to be able to find them. Mutt usually sits > running in a dedicated terminal on one of my workspaces with the > 'main' inbox displayed so I just need to glance at that to see any > non-list E-Mails. That is also my usage pattern. If a script like Chip Camden's, or one in Gawk, running as a coprocess to mutt, could steer mutt's mail "Newness" decisions, then mutt's current erroneous behaviour could be fixed, possibly using more effort than is necessary. I would be delighted to write, debug, and maintain the coprocess, if it were necessary to go that way. While that would be a lot of fun, mutt itself does seem able to be cured of its current fibbing behaviour. (Try copying this message to this mail folder. Mutt says "New mail in this mailbox." What hokum.) Mutt needs to check the size and/or atime of the destination folder _before_ it writes, rather than cookily doing it _after_. Then the erroneous and misleading immediate message would go away. To fix the problem of mutt adding the transfer recipient folder to its list of "New" folders on its next scan, another small bugfix is also required. Once the recipient file has been written, mutt needs to update its current values for file size and atime, so that the "Newness" reference will be correct. Would that not put an end to its fibbing ways? Erik -- Never worry about theory as long as the machinery does what it's supposed to do. -- Robert A. Heinlein
