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

[Juri Linkov]

>> So e.g. after navigating from *grep* to window A, and from *compilation*
>> to window B, next-error invoked from windows A or B will continue
>> the right navigation.
>
> Suppose you've did that, then turned left to look out of the window for
> half a minute, then looked back at Emacs. How are you going to predict what
> M-x next-error will do?

You can see an arrow indication in the left fringe of the navigational window
that points to the location of the current file displayed in an adjacent window.

> But my first choice is to not rely on buffer visibility at all, and simply
> follow the current global next-error-last-buffer value, as well as provide
> an easy way to switch to a different one.

I just posted an IDE-like layout to emacs-devel, and it demonstrates that the
current rule#1 in next-error-find-buffer is the right thing to do in this
scenario: after switching from e.g. *grep* to *xref* in the bottom window,
next-error will continue navigation from the visible navigation buffer.
So no changes are required in this case.

>> I proposed window-local next-error-last-buffer only because you had
>> some problems with this rule using in xref.
>
> Yes, I did. But IIUC, Eli had more of a problem with the
>
> (if (eq (length window-buffers) 1)
>
> part of that rule. The commit that disabled next-error integration in xref
> has a link to that discussion in its message.

The rule (if (eq (length window-buffers) 1) itself is not a problem.

The problem is in the cases that this rule doesn't support, i.e.
(< (length window-buffers) 1) and (> (length window-buffers) 1)
We need to find a way to handle these cases as well.

>>> How will you switch between Grep and Compilation if they display a location
>>> in the same buffer (and window)? Won't the desired navigation buffer have
>>> to be visible? So you'd have to select some window, switch to that buffer
>>> in it, and then click or press RET on some error?
>>
>> Yes.
>
> Lots of clicking.

No clicking at all, I don't use the mouse :)