On Tue, Nov 29, 2022 at 11:35:11AM -0800, Kevin J. McCarthy wrote: > On Tue, Nov 29, 2022 at 02:19:26PM +0100, Oswald Buddenhagen wrote: > > On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev > > wrote: > > > + ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) > > > after > > > + ** this many seconds. A zero (default) or negative value causes Mutt > > > to wait > > > + ** indefinitely for the read to complete. > > > > > have you checked how this plays along with imap IDLE? > > Thanks Oswald. I'll take a closer look before committing, but I don't think > it should have a particular effect, at least for Mutt's implementation. > Mutt sends IDLE, polls the socket for up to $imap_poll_timeout, and then > reads looking for the "+" response.
It's possible I'm not exercising all corner cases here, but to add some empirical data: just tried running this patch with imap_idle and a relatively small receive_timeout for a bit, and didn't notice any difference in behavior. Even with receive_timeout=0, imap_idle=yes, my Mutt config only seems to (intentionally) do long-blocking reads on stdin/waiting for user input. imap_check_mailbox sets up the idle with the server and returns quickly after that, with or without receive_timeout. Thanks for all the feedback, Matthew
