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

[Juri Linkov]

>> The primary question is not how many users asked for it many years ago,
>> but how many users are using it now.
>
> You're welcome to poll, but so far we only have the data about
> a single user.

Yes, a single user who wants to remove it ;)

>> Obviously, get-mru-“next-error”-window, i.e. a combination of both.
>
> I have no idea what that means, really. Are we going to store a reference
> to a window instead of a reference to a buffer? And then take the reference
> to the buffer from that window?

Just traverse all windows in the order of recency until finding a window
with next-error-function.

>>> And, again, this ignores the Flycheck case.
>>
>> Alas, this means we have to trade visibility of next-error-last-buffer
>> for window-local values.
>
> What means? And why?

In case of Flycheck it's next-error-last-buffer is the current buffer
and is always visible.

>>> With your approach, no window will affect other windows. Even if I ran M-x
>>> rgrep, and I see its buffer in the current frame, I'll also have to
>>> remember which window it ended at. And if I never clicked on a link in the
>>> *grep* buffer, I can't use C-x ` in any window, I'm assuming.
>>
>> C-x ` in any window will use the global value, i.e. the last navigation.
>
> So, not only we'll have local values, we'll also have a global one?

When there is no local values, then indeed use a global one.

> Upon invoking that command, will focus immediately jump to the one window
> associated with the navigation buffer?

Naturally.

>>> Suppose I use flycheck-next-error in foo.el. And I have a *grep* buffer
>>> visible, and I jumped to bar.el from it. And the next error in *grep* is in
>>> foo.el. What happens when I, having returned to bar.el's window, call
>>> next-error again? Does it jump to foo.el's window? Does it display foo.el
>>> in the window where bar.el previously was?
>>
>> It will display foo.el in the window where bar.el previously was.
>
> Aren't you at all worried about running out of windows (and not being
> allowed to split them)? In our last discussion with Martin, he expressed
> concern that some users use one window per frame. In this scenario, you'll
> need at least 3. And with two navigational buffers visible, the number of
> necessary windows will grow to 5.

I meant reusing an existing window with a file buffer, not creating a new
window.  I see no reason not to use this behavior by default.

>> AFAIS, this is the point of the current discussion on emacs-devel -
>> to fix xref's window management to work like *compilation* and visit
>> navigated windows predictably.
>
> *compilation* isn't afraid to use different windows when it's
> convenient. It definitely reuses another window if the buffer it's going to
> jump to is already displayed.

What I see is that *compilation* always reuses another window to not replace
the navigational *compilation* buffer with a file buffer.  Do you know
under what circumstances this behavior might fail.

>>> But if we have a new command, I could also allow selecting from some of the
>>> existing buffers which contain "nonlocal" next-error-function's.
>>
>> Why only “nonlocal”?
>
> Because otherwise there'll be too many options too choose from. To use
> a different buffer, the user can switch to it first anyway.
>
> Nonlocal next-error-functions represent groups of windows that are somehow
> related (parts of the same problem, matches for the same input, or so
> on). And with them, we can at least expect that the next error still might
> be in the current buffer.

This is why I proposed window-local variables to bind a group of windows
to their parent navigational window.