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 <eric@ericabrahamsen.net>]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

> Uh, I had technical issues and did not get all mails as I expected.
> Cobbling things together in one big reply now, with references and
> quotes hopelessly broken ... hope you can sort it out.
>
> Anyway, thanks to Eric for chiming in.
>
>> Ideally, it would be nice to have tests, though I have no clue how to
>> approach writing them.
>
> I have created a somewhat minimal Gnus setup to develop and test this
> patch on my development laptop, where I normally do not use Gnus.  It
> consists of a bunch of files and directories and a bit of configuration.
> I can follow up on this if you like, but preferably in a separate
> thread.

Someone mentioned gnus-mock in the other thread, which I made for
exactly these scenarios. It's a bit hairy making a Gnus installation
from nothing -- if you try it out and would like it to do something
different, I'd be interested in feedback.

>>> 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 [...].
>
> Not really.  The following executed in an article buffer:
>
>   (progn
>    (kill-buffer gnus-summary-buffer)
>    (gnus-article-show-summary))
>
> results in
>
>   Debugger entered--Lisp error:
>       (error "There is no summary buffer for this article buffer")
>     signal(error ("There is no summary buffer for this article buffer"))
>     error("There is no summary buffer for this article buffer")
>     gnus-article-show-summary()
>     [...]
>
> Which, OTOH, shows that I was wrong in one aspect: Gnus at least in some
> cases *does* give a reasonable error message when the summary buffer for
> an article buffer is gone.
>
>>> 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)
>
> I agree with Ihor here and would rather go for individual wraps into
> `with-current-buffer'.  As I have done in my patch already,
> incidentially.

Somehow I missed that this whole thread started with an actual patch!
Sorry, that should have been the subject of discussion the whole time. I
can help with applying it, once all issues are resolved.

Thanks,
Eric