bug#43682: 28.0.50; Clean up nnimap server buffers?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 09/30/20 03:18 AM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Do we need to manipulate `nnimap-connection-alist', as
>> `nnimap-find-connection' does? I've never understood what that variable
>> is actually for. It's a defvoo, so it has a separate value per-server,
>> but each server's only got one active process buffer anyway.
>
> They do?  I thought async prefetching opened a second connection.  Is
> that in nnimap only?

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'.

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.

> And... was there something about sieve-mode having its own connection?
> I forget.

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.)

I went back through nnimap.el as carefully as I could. It's
`nnimap-find-connection' and `nnimap-open-connection' that end up making
use of `nnimap-connection-alist', but both of them only ever use
`nntp-server-buffer' as the alist key. Unless that's been sneakily
let-bound to something different someplace, the
`nnimap-connection-alist' doesn't appear to do anything.

Also, `nnimap-make-process-buffer' sets a buffer-local version of
`after-change-functions' to nil -- this looks a bit like how nntp
handles its async code, but it isn't used in nnimap. My guess is that
someone set out to implement async for nnimap, but never quite finished
it.

I'm inclined to delete the alist altogether, but if we keep it at least
I can give it a docstring.

Eric