Ihor Radchenko <yanta...@posteo.net> writes: > Eric Abrahamsen <e...@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
