Re: Detecting new mail in mbox format
On Sat, Apr 25, 2009 at 01:22:19PM EDT, Grant Edwards wrote:
> On 2009-04-25, Chris Jones <cjns1989@xxxxxxxxx> wrote:
[..]
> > buffy-list .. list mailboxes with new mail
> 1) That's not what I said I wanted to do. I don't want to
> check "mailboxes" for new mail. I want to check the
> current folder for new messages.
Still not sure what you meant.
What matters to me is that mutt should notify me of the delivery of new
mail, and where it was delivered.
In any case, I have a feeling that one reason I misunderstood you in the
first place is that in my setup this has worked from day one without my
having to do anything - i.e. I never had to "check" anything because I
was automatically notified.
I use the mbox format, I run fetchmail on demand to download internet
mail when I feel like it and procmail takes care of dispatching my mail
to their respective mailing lists folders or to my =Inbox.
$mail_check is set to "5", which I assume to be the default and $timeout
is set to "120" in my .muttrc.
I changed the latter to "10" and ran the following tests:
1. I changed to the index screen of my Inbox, sent a message to
myuser@localhost, noticed a "Mail sent" notification at the bottom of
the screen, waited ten seconds, and "Mail sent" was replaced by a
"New mail in this mailbox." (without refreshing the screen via a
keyboard action).
2. From the same mutt index screen of my Inbox, I sent a message to one
of my internet email addresses, followed up by a 'Shift-g' (which is
mapped to "!fetchmail -m 'usr/bin/procmail .. etc.". A half-screenful
of messages informed me of the progress of my download, followed by a
"Press any key to continue...". I hit Enter and was notified by a
message similar to the one above that read "New Mail in =Inbox,
=lists/debian-user.. etc."
Apologies for the verbosity, I'm trying to be thorough.
In both cases, I verified that the "buffy-list" function was giving me
the correct results.
After test (1) the buffy-list notification read "New mail in =Sent"
which I think makes sense in roundabout way: since I was in my Inbox
folder's display already, mutt did not "see" the new message in my Inbox
as "new" any more, just unread.
Similar message after test (2) with =Inbox + a few mailing list folders.
In both cases I changed to the "browser" view of my ~/mail tree where my
mail lives and all the folders that contained new messages were
correctly flagged with a capital "N".
After test (2), I accessed all the folders that had been flagged for
N-ew mail in succession thereby changing their status and then hit "."
and this time the "status line" remained empty (which I think is not
quite right, mutt should display "No new mail." or something to that
effect).
I was unable to access email for the last few days and I have probably
missed some developments, but I did skim through this thread before
posting this reply and apart from the fact that you use maildir's (?)
which shouldn't matter, the main difference appears to be that while
_my_ mail as far as mutt is concerned is always local (becomes local
after I run fetchmail), _yours_ on the other hand is stored on remote
IMAP-managed servers.
So I would suspect that directly or indirectly this has something to do
with your mutt's behavior.
My feeling about this is that since mutt's interface in this respect is
functionally adequate in a local mail context, unobtrusively providing
the user with all the notifications he needs both in "real time" - and
"after the fact" via the buffy-list function, it should work exactly the
same when your mail happens to be on remote servers.
No reason why the interface should not be consistent.
Maybe you should open a bug report about this issue with all the details
of your setup & the exact scenarios..?
> 2) I just tried it, and it does nothing. It's bound to '.'.
> When I hit '.' absolutely nothing happens. No IMAP commands
> are sent to server to check either the current folder or
> the folders in the "mailboxes" list.
Not sure how IMAP works since I don't use it.
I thought that in this context, the MUA typically maintains a cache with
the headers of the messages available on the server(s) and that the body
of a particular message is only downloaded when the user decides to
access the given message... ??
If this is the case, wouldn't you need to map some keyboard action to
something like "refresh cache" followed by "buffy-list" for this to
successfully inform you of the delivery of new mail?
CJ