Re: mutt/2152: new read mail in IMAP folder not seen
The following reply was made to PR mutt/2152; it has been noted by GNATS.
From: Brendan Cully <brendan@xxxxxxxxxx>
To: Phil Pennock <muttbug@xxxxxxxxxxxxxxxxx>
Cc: bug-any@xxxxxxxxxxxxx
Subject: Re: mutt/2152: new read mail in IMAP folder not seen
Date: Thu, 15 Dec 2005 15:24:06 -0800
On Thursday, 15 December 2005 at 23:22, Phil Pennock wrote:
> On 2005-12-15 at 10:52 -0800, Brendan Cully wrote:
> > not new. That code hasn't changed in years. It's not related to the
> > bug you described either - polling other mailboxes is done completely
> > differently from polling the selected one.
>
> In that case, one of your recent changes has had a major impact on how
> well this works, because I'd bound <Esc>$ through necessity. So gratz
> there. Sorry for not knowing, but this is the first time that I've had
> cause to build a +DEBUG mutt.
In hindsight it strikes me that the problem was probably that your
$timeout was much too high. The new IDLE code isn't dependent on
$timeout, but NOOP was. $timeout has a default which isn't suitable
for IMAP.
> > I'm currently playing with a rewrite that uses UIDNEXT instead of
> > RECENT to work around the ephemeral nature of the RECENT flag, but it
> > will actually be marginally more expensive for the server.
>
> I'm interested in helping to test this; would it be best for me to join
> mutt-dev@ ?
Sure, I'll be posting the announcement there when I've got it working
to my satisfaction locally.
> > New mail in the current mailbox is checked with NOOP or IDLE,
> > which should be very cheap.
>
> Not guaranteed to return status updates, though, IIRC. I guess that's
> why you're not getting rid of imap-fetch-mail immediately though, to
> wait to see just how brain-dead some of the smaller servers are?
It's because not everything supports IDLE...