On Wed, May 31 2017 12:25:13 -0700, Kevin J. McCarthy wrote: > On Wed, May 24, 2017 at 09:34:12AM -0700, Kevin J. McCarthy wrote: > > On Wed, May 24, 2017 at 05:19:01PM +0300, Lauri Tirkkonen wrote: > > > I noticed that while mutt does support eg. IDLE for IMAP, it's not quite > > > as useful as it could be because recv() is not actually called on the > > > socket until timeout happens or terminal input is received. I made this > > > horribly ugly patch that uses select(2) instead of waiting on just stdin > > > -- it makes new mail/flag changes appear pretty much instantly if IDLE > > > is used. It's mostly just a proof of concept: a clean implementation > > > would require some more work around how input is handled. > > > > Thank you for the patch. I _will_ take a look at this, but I have a few > > things on my todo list I need to work my way through first. > > I've finally had a chance to take a closer look. I understand this is > just a concept patch, but I'm not really keen on the idea. > > It's needing to peek into the input buffers (and should really be > checking MacroBufferCount too). It's poorly/partially duplicating code > in imap_keepalive() and imap_check_mailbox(). It makes km_dokey() even > messier, and since that is used in many other places than the index, > causes spin loops in places that don't care about the updates.
Yep, you're correct -- km_dokey really does not feel like the correct place to handle this. But that's because currently mutt's "main loop" is basically just getch() in there (and as you mentioned, km_dokey may be called from various places). To do this correctly would require larger restructuring. > And all this, just to get updates slightly faster, which could also be > accomplished by setting $timeout to a smaller value. Sure. However there's bugs there too: set timeout to (say) 5, tag a message, hit tag-prefix, wait 5 seconds and observe "Key is not bound". I'm not an expert on mutt code but deferring all IO until some happens on stdin feels wrong to me. > As always, I invite the other devs to take a look (especially Brendan, > if you have a moment). But for now, I don't think I'm interested in > this proposal. Ok, I understand. I could try to put together something better that requires larger changes if you like (and if I find the time). -- Lauri Tirkkonen | lotheac @ IRCnet
