Jens Schmidt <jschmidt4...@vodafonemail.de> writes:
> On 2023-07-22 15:48, Ihor Radchenko wrote:
>
>> I am not familiar with Gnus, but looking at the code, may it be that
>> a Gnus article is open when Gnus summary buffer is not?
>
> Theoretically yes, if you actively and malignantly kill the summary
> buffer, for example. In practice and through Gnus key bindings, this
> should not happen. IOW, Gnus stops behaving reasonably as well if you
> kill the summary buffer other than through Gnus key bindings
> ("Selecting deleted buffer", etc.).
>
> If you check function `gnus-summary-work-articles' from gnus-sum.el, the
> main work horse for article processing and also good for calling in
> article buffers, you will note (focusing on the default case) the same
> paradigm
>
> (with-current-buffer gnus-summary-buffer
> (cond
> [...]
> (t
> ;; Just return the current article.
> (list (gnus-summary-article-number))))))
>
> As a last resort we could also try to drag in Andrew Cohen as a
> reviewer, he has been helpful already with one or two of my Gnus bugs.
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.
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.
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.
Eric
