bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason

[Dmitry Gutov]

On 01/29/2016 02:59 AM, Juri Linkov wrote:

> ...and allowing switching
> to another navigation.

Are you coming around to my suggestion now?

> > The rule#1, as written, also poorly interacts with Flycheck-like use
> > cases. Are you going to comment on that part discussion?
>
> Flycheck provides its own keybinding ‘C-c ! n’ for ‘flycheck-next-error’,
> so really there is no problem.

That's basically giving up.

Do you expect me to repeatedly type `C-c ! n' to move across errors in 
the current buffer? It's not like it's inconvenient or anything. 
next-error-function was added exactly so that the user doesn't have to 
learn a bunch of different key bindings for basically the same thing.

There's also e.g. js2-mode, which doesn't have a custom key binding for 
this. And probably other modes that I just don't know about.

> A real problem is when a navigational buffer does exist, but it's hidden.
> IIUC, due to this problem you reverted next-error integration in xref, right?

No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html

See the first sentence there.

> > We can also realize that the rule #1 is an attempt to do the following: if
> > next-error-last-buffer is no longer visible, try to pick a navigational
> > buffer among the currently visible ones.
>
> You mean next-error-last-buffer is no longer visible _on the selected frame_?

I don't really care either way. This question doesn't seem to add any 
big constraints on the final solution.

> Yes, this is because it's hard to find a better way, and I'm not sure
> how next-error-function-nonlocal could help, because sometimes a navigation
> might visit another non-file navigational buffer, e.g. multi-occur
> visiting a *compilation* buffer.

What is the exact problem you have in mind there?

When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps 
referring to *multi-occur*.