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

[Juri Linkov]

>>> No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html
>>>
>>> See the first sentence there.
>>
>> I reread it every time you reference it, but it adds nothing to the 
>> discussion.
>> Could you provide more details about this problem.  I imagine you meant the 
>> case
>> when *xref* is hidden, but *compilation* is visible.  Is it so?  What are the
>> preconditions for this situation to occur?
>
> You really should ask Eli what exactly he meant there, I'm just
> guessing. I didn't want to keep inquiring at that point. Eli said disable,
> so I disabled.

I believe Eli meant this case because it's hard to imagine another one.
So we have to find a solution for this case.

By setting a window-local value of next-error-last-buffer in the
selected window, we can continue the xref-navigation even when
*compilation* is visible in an adjacent window.

> But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the
> configuration with three buffers with next-error-function set visible. Hide
> the current last-buffer: nothing changes, `next-error' continues working as
> it did. Hide the next one: and suddenly, `next-error' starts
> behaving differently.

When the number of next-error-function windows is more than one, then
there's a dilemma which one to use.

>> This is why I proposed to use window-local values, and your counter-arguments
>> against it (indication/switching) apply to the already used global value
>> of next-error-last-buffer as well: its current state is not discoverable
>> and it's not easy to switch to another navigation.
>
> Your proposal _complicates_ the current state, making it more of
> a problem. If the global value of next-error-last-buffer is used
> consistently, at least the current state is easier to remember.

But it allows the user to continue a paused navigation in another window
in another frame, thus having several simultaneously active navigations
in different windows.

> The actual problem is that `next-error' exhibits surprising behavior,
> and doesn't properly support `next-error-function' being set in
> file-visiting buffers, which is a common situation these days.

What happens when two features set `next-error-function' at the same time?
I guess the latest wins, so there is no problem no matter if using
visibility of next-error-last-buffer or window-local values.

> Since filing this bug, I've somewhat warmed up to using buffer visibility
> as a condition to choose next-error-last-buffer.

Visibility of next-error-last-buffer is not suitable for navigations
without a navigational buffer.