Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Eric Abrahamsen]

Ihor Radchenko <yantar92@posteo.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> We should definitely be using the paradigm above (using the
>> gnus-summary-buffer as the current buffer). The article number fetching
>> only works by accident in the article buffer, and other stuff (like
>> finding the original nnselect group name) won't work at all.
>
> I am convinced then.
> Ideally, it would be nice to have tests, though I have no clue how to
> approach writing them.
>
>> Later in the function we've got this:
>>
>> (save-window-excursion
>>   (save-excursion
>>     (gnus-article-show-summary)
>>     (gnus-summary-article-header)))
>>
>> If we're currently in article-mode. The call to
>> `gnus-article-show-summary' would protect against the case where the
>> summary buffer has been killed in the meantime, but I agree that's kind
>> of a pathological case.
>
> I'd say that the patch will be an improvement anyway.
>
>> Probably it would be enough to wrap the whole containing `let*' in a
>> (with-current-buffer gnus-summary-buffer ...). If we're already in the
>> summary buffer, no harm done.
>
> I am not sure if it is safe.
> There is
> (save-window-excursion (gnus-summary-select-article))
> which calls (set-buffer gnus-summary-buffer)
>
> `with-current-buffer' will certainly alter how things work (although,
> switching buffer when capturing link is already fishy).

Ugh, this whole thing is a mess. I think the first question is: should
this function "fix" the state of Gnus before it makes a link? Should it
attempt to re-open the Summary buffer if it's been closed? Should it
switch current articles if the open article buffer is not the one that
point is on in the Summary buffer?

If we make a decision about that, then it should be easier to decide how
to handle the code changes themselves.

Eric