GNU bug report logs - #43682
28.0.50; Clean up nnimap server buffers?

Previous Next

Full log

Message #29 received at 43682 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43682 <at> debbugs.gnu.org
Subject: Re: bug#43682: 28.0.50; Clean up nnimap server buffers?
Date: Wed, 30 Sep 2020 22:09:11 -0700

[Message part 1 (text/plain, inline)]

On 10/01/20 03:30 AM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> So that's what it's for! That's a mystery solved. It appears that only
>> nntp is asynchronous: at least, it's the only backend that implements
>> `gnus-asynchronous-p'.
>
> Aha.  nnimap should, too.
>
>> nntp.el also contains `nntp-async-{wait,stop-trigger}', but as far as I
>> can tell that has nothing to do with gnus-async.el stuff (?). That's the
>> code that appears to make use of "extra processes per server", and
>> nnimap doesn't have any of that.
>
> Yes, that's a separate thing...
>
>> Not so far as I can tell. sieve.el and sieve-mode.el don't have anything
>> to do with Gnus, and gnus-sieve.el is just about building sieve scripts
>> from Gnus splitting rules. (Now that you mention it, it would be nice if
>> there were a command to edit an IMAP server's sieve scripts from the
>> *Server* buffer.)
>
> Right.  I think there was once some talk about this stuff, but oy vey
> the years...

I'll add it to my own todo list, where it can likewise languish for
years.

>> I'm inclined to delete the alist altogether, but if we keep it at least
>> I can give it a docstring.
>
> No, we should keep it and implement the stuff for gnus-asynchronous-p in
> nnimap, too.

It's possible (I'm not claiming to understand all the code) that all we
would need to do is fix `gnus-async-wait-for-article' to replace its
calls to `nntp-find-connection' and `nntp-accept-process-output' with
something generalized. Those two functions deal with directly with
`nntp-connection-alist', so we'd need something that would do the
equivalent with `nnimap-connection-alist'.

Anyway, in the interest of completing this far less ambitious patch: if
the nnimap connection has timed out, we should remove this connection
from `nnimap-connection-alist', so this version of the patch does that.
If async has opened a second connection, I guess we should leave that
alone, though I don't have too much confidence that the whole process
will recover gracefully from the main connection dying...

Eric

[CleanupImapBuffers.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.