bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented

[Dmitry Gutov]

On 20.05.2020 01:21, Juri Linkov wrote:
> > > Another variant would be
> > > to add an optional choice to the existing option that allows to restore
> > > the old behavior and doesn't affect the current behavior in any way.
> >
> > FWIW, I'd consider that more of a documentation change.
> >
> > More importantly, and certainly only for Emacs 28, Juri could you remind me
> > what we'll be losing by removing the case no. 2 from
> > next-error-find-buffer?
>
> It is used to handle such cases when navigating one next-error list
> visits a buffer that contains another next-error list - visiting
> such buffer should not switch the navigation, it should continue
> the initial navigation.

Didn't we fix changelog-mode so this doesn't happen anymore? I think as 
long as file major modes don't set next-error-last-buffer (and minor 
modes either, on initialization), we should be safe.

Can you reproduce a problematic scenario with the attached patch?

> But I'm not proud of the case no. 2, so you can drop it :)
>
> Or better move it to a separate function and provide this function
> as an option in next-error-find-buffer-function.

Patch attached. Comments welcome.

> > The ability to switch to an arbitrary Grep buffer and start using it with
> > 'M-x next-error'? E.g. if there are several of them. That's more of
> > a backward compatibility concern, right? Or do you have scenarios in
> > mind where this will really save on keystrokes?
>
> The ability to visit an arbitrary Grep buffer and use 'next-error' in it
> to switch navigation should always work as the most reliable and implicit
> way to switch navigation.  This is the case no. 3 in next-error-find-buffer.

Not if there are, say, two Compilation buffers (or Grep and Occur, etc), 
and you switch to the least recently used one, and press M-g n.

It's probably fine, though.

> > On another note, perhaps we could add a message to next-error-select-buffer
> > that would be shown if we suspect this command will not have the expected
> > result for the user.
>
> Or maybe ask the user using the minibuffer to resolve ambiguity.

Resolve it how? I think we can safely guess their intention, it's just 
not trivial to execute it.

Anyway, this problem should go away with the attached patch.

next-error-extract-case-2.diff
Description: Text Data