* bug#20319: nnoo.el not properly restoring back end server state
[not found] ` <877f5hzotn.fsf@gnus.org>
@ 2017-01-26 19:55 ` Alain Schneble
2018-04-12 21:11 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Alain Schneble @ 2017-01-26 19:55 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20319
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Sorry for the late response; due to a misunderstanding the Gnus bug
> reports went to a part of the bug tracker I wasn't checking.
No problem at all. Thanks for bringing this up.
> Alain Schneble <a.s@realize.ch> writes:
>
>> Anyway, evaluating nnoo-state-alist again shows that server's B state
>> would still be available but is not found because it's listed before nil
>> server's data:
>> => (... (nntp nil ("B" (nntp-address . "news.gnus.org") ...) (nil (nntp-address) ...)) ...)
>>
>> IIUC, this behavior is wrong.
>>
>> 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.
>>
>> But I might be wrong. What's the use case of re-pushing nil server's data?
>
> I think you're right, but I haven't looked at the code closely. Could
> you suggest a patch to fix this problem, perhaps?
Sure, I'll arrange a patch. Please, just give me a few days...
Alain
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#20319: nnoo.el not properly restoring back end server state
2017-01-26 19:55 ` bug#20319: nnoo.el not properly restoring back end server state Alain Schneble
@ 2018-04-12 21:11 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-12 21:11 UTC (permalink / raw)
To: Alain Schneble; +Cc: 20319
Alain Schneble <a.s@realize.ch> writes:
>>> 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.
>>>
>>> But I might be wrong. What's the use case of re-pushing nil server's data?
>>
>> I think you're right, but I haven't looked at the code closely. Could
>> you suggest a patch to fix this problem, perhaps?
>
> Sure, I'll arrange a patch. Please, just give me a few days...
It's now been a few days. :-) Did you whip up a patch in the meantime?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#20319: nnoo.el not properly restoring back end server state
[not found] <86r3rng4gy.fsf@realize.ch>
[not found] ` <877f5hzotn.fsf@gnus.org>
@ 2019-09-27 0:15 ` Lars Ingebrigtsen
2019-09-29 1:10 ` Eric Abrahamsen
2019-10-14 7:29 ` Lars Ingebrigtsen
1 sibling, 2 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 0:15 UTC (permalink / raw)
To: Alain Schneble; +Cc: 20319
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?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#20319: nnoo.el not properly restoring back end server state
2019-09-27 0:15 ` Lars Ingebrigtsen
@ 2019-09-29 1:10 ` Eric Abrahamsen
2019-09-29 10:39 ` Lars Ingebrigtsen
2019-10-14 7:29 ` Lars Ingebrigtsen
1 sibling, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2019-09-29 1:10 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20319, Alain Schneble
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#20319: nnoo.el not properly restoring back end server state
2019-09-29 1:10 ` Eric Abrahamsen
@ 2019-09-29 10:39 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-29 10:39 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 20319, Alain Schneble
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> 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
Yup. This should now be fixed on the trunk.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#20319: nnoo.el not properly restoring back end server state
2019-09-27 0:15 ` Lars Ingebrigtsen
2019-09-29 1:10 ` Eric Abrahamsen
@ 2019-10-14 7:29 ` Lars Ingebrigtsen
1 sibling, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-14 7:29 UTC (permalink / raw)
To: Alain Schneble; +Cc: 20319
Lars Ingebrigtsen <larsi@gnus.org> writes:
> 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?
More information was requested some weeks back, but no response was
given, so I'm closing this bug report. If you're still seeing this
problem, please reopen.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-14 7:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <86r3rng4gy.fsf@realize.ch>
[not found] ` <877f5hzotn.fsf@gnus.org>
2017-01-26 19:55 ` bug#20319: nnoo.el not properly restoring back end server state Alain Schneble
2018-04-12 21:11 ` Lars Ingebrigtsen
2019-09-27 0:15 ` Lars Ingebrigtsen
2019-09-29 1:10 ` Eric Abrahamsen
2019-09-29 10:39 ` Lars Ingebrigtsen
2019-10-14 7:29 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).