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

[Juri Linkov]

> Maybe it's a good idea, but I'm not sure how to enforce something like
> that, to be able to rely on it. And a small arrow in one window is not
> a great indicator anyway.

A good indication could be provided by a new global minor mode
‘global-next-error-minor-mode’ showing in the mode line
the currently active navigation, and allowing switching
to another navigation.

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

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?

> 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_?

> However, the rule tries to limit the number of visible navigational buffer
> to one, and aborts otherwise. I think that's because it doesn't know any
> better way to distinguish between navigational buffers and plain
> file-visiting buffers that have next-error-function set locally
> (navigational buffers can also be file-visiting, as in the cases of
> change-log-mode and diff-mode). The new variable that I proposed
> would help.

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.