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

[Juri Linkov]

>> The link to the discussion is here:
>> http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00614.html
>> where you can see the case that we need to support.
>
> In this scenario, it seems like you could have benefited from
> next-error-last-buffer value being frame-local instead (maybe implemented
> as a frame parameter?).

A frame might contain more pairs of navigational/target windows,
e.g. a window with *grep* output, and a file buffer visited from *grep*;
a window with *Occur*, and another place in the same file buffer
but visited from *Occur*, etc.

So frame-local is not of help here, whereas window-local is,
provided a navigational window (like *grep*/*compilation*)
always displays target buffers in another dedicated window.

As I see this is not what xref currently does: navigating in it
jumps between many different windows that is very inconvenient,
but this can be easily fixed to work the sane way as *grep*
or *compilation* already works.

>> Now that we have window-local variables, it's possible to support
>> this case in a proper way.  Instead of checking if a buffer visible
>> in the current frame, we should check the window-local value of
>> next-error-last-buffer.  Thus invoking next-error in the window
>> with the source buffer will continue navigation using the right value
>> of next-error-last-buffer that navigated to its previous occurrence.
>
> How do linting minor modes (like Flycheck or Flymake) fit into this?

Does Flycheck or Flymake display a navigation window with a list of results?
If not, then this is a new case that we need to support as well.

> Suppose I called M-x compile (or, better yet, M-x grep), navigated to some
> file buffer from it and then see that it has some linter errors highlighed
> by Flycheck. So I want to use the current buffer's next-error-function now,
> and jump between linter warnings using next/previous-error. How do I do
> that? IIU your plan correctly, the current window-local
> next-error-last-buffer value will continue pointing at the Grep buffer,
> even if I bury it.

What if you have two navigations in the same buffer, and both are
without a navigation window that you can't bury?

> Basically, I want to have two at least somewhat guessable sequences of
> actions that would let the user choose which buffer to use for its
> next-error-function.
>
> As discussed in this issue, the best way to do that seems to require:
>
> - Some indicator that a given buffer's next-error-function points to other
> buffer (then, if you're in a different buffer, that other buffer is still
> relevant). Like a buffer-local variable called, for example,
> next-error-function-nonlocal.

Do you mean to bind a navigation buffer with navigated target buffers/windows?

> - A command (or several) to switch between the plausible candidates for
> next-error-last-buffer. Maybe just have a single command that uses
> read-buffer with a predicate checking the aforementioned variable and an
> extra option that means "just use the current buffer".

This would be too complicated to use.

> - Ignore next-error-last-buffer's visibility. Or make it frame-local, to
> account for your scenario as well (but that would bring extra complexity:
> some people use use frames like almost separate applications, and other can
> use frames instead of windows, and display them side-by-side).

Buffers are displayed in windows, so better to bind them to windows.

> WDYT?

I remember the original idea was to always continue the same navigation
that displayed a given target buffer/window, so switching to another
navigation in the same window could be achieved by explicitly navigating
to another result from another navigation, e.g. when current navigation
was from *compilation* then switching to *grep* buffer and typing M-n
for the next grep hit in the same file buffer.