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/)]

[Jens Schmidt <jschmidt4gnu@vodafonemail.de>]

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.

 >> 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.

 >> 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.
 >
 > ol-gnus should store link for thing at point in current buffer. Ideally,
 > without side effects. Everything else should be implementation detail.

Could we agree on: ol-gnus should store Gnus links with as little effort
and side-effect as possible while providing reasonable functionality for
the common use cases.  I think, again incidentially, that my patch
matches this criterion.

What optionally could be improved, though, is error handling in these
pathological cases.  But that would probably require some macro

   (ol-gnus-with-current-summary-buffer BODY)

to have the error handling available in the separate places.  Not sure
whether this is worth the effort.

 > Or, at least, it was not sufficient at the time when ol-gnus has been
 > written (quite a while ago).

I don't think this has changed, really.