bug#20319: nnoo.el not properly restoring back end server state

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Alain Schneble <a.s@realize.ch> writes:
>
>> Hi,
>>
>> nnoo.el does not properly restore back end server state from
>> nnoo-state-alist after closing one server (say server A) and reopening
>> another (say server B), given that both servers use the same back end
>> (server method). Cached state of server B won't be restored at all in
>> this case.
>>
>> Steps to reproduce:
>>
>> 1. M-x gnus-other-frame
>> 2. M-x gnus-group-enter-server-mode
>> 3. For each server: M-x gnus-server-close-server
>> 4. Repeat twice, once with [server] = A and once with [server] = B:
>>    a) M-x gnus-server-add-server
>>    b) nntp
>>    c) [server]
>>    d) M-x gnus-server-edit-server
>>    e) Adapt shown elisp form to:
>>       (nntp "[server]" (nntp-address "news.gnus.org"))
>>    f) C-c C-c
>> 5. On server A: M-x gnus-server-open-server
>> 6. On server B: M-x gnus-server-open-server
>> 7. On server A: M-x gnus-server-close-server
>
> [...]
>
>> Also, I do not understand why nil server's data is stored (re-pushed)
>> onto the nnoo-state-alist by nnoo-push-server at all.  My understanding
>> is that nil server's data shall be immutable once it's been initialized.
>
> I've done some tracing here, and I think that possibly the problem here
> is that nn*-close-server is called with incomplete data: It's only
> called with the server name, and not with the actual address.
>
> I've now changed this in the interface function in Emacs 27, and things
> look more regular now, but the recipe here to reproduce was a bit
> ... long, so I'm not 100% sure.
>
> Would it be possible to upgrade and check?

Looks like nndraft-close-server also needs to be updated, but I guess
it's dynamically generated (?) and I don't know where. Trying to close
the draft server gives:

gnus-close-server: Wrong number of arguments: (lambda (&optional server)
(nnoo-close-server 'nndraft server)), 2

Thanks,
Eric