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

[Dmitry Gutov]

On 02/01/2016 12:57 AM, Juri Linkov wrote:
> > In the message above, he was replying to my message, where I said: "On the
> > other hand, while *xref* is visible, `next-error' will keep working for its
> > results".
>
> Clearly, this describes a successful case as opposed to the problematic one
> where *xref* is hidden that evidently needs fixing.

Yes. This was my appeal to keep the existing integration of xref with 
next-error-function. Eli disagreed.

What can we gather from that?

> > On the other hand, if we just use the global next-error-last-buffer value,
> > we'll just as well "continue the xref-navigation even when *compilation* is
> > visible in an adjacent window".
>
> And lose the support for the case of simultaneously active navigations
> in different windows/frames.

Yup. Did you have many requests, from different users, before 
introducing this support?

> > > When the number of next-error-function windows is more than one, then
> > > there's a dilemma which one to use.
> >
> > Let's use the last one. That would definitely simplify things.
>
> Indeed, using (get-mru-window 'visible t t) makes sense.

I don't follow. The window returned by the above won't necessarily have 
next-error-function set. And, again, this ignores the Flycheck case.

> > If the "previous" navigation buffer is visible, you can also continue
> > navigation by going to it, and using one of the links there.
> >
> > If it's not visible, it would make remembering which window belongs to
> > which navigation, even more difficult.
>
> Isn't it so that the user will remember which navigation displayed
> a given window?

Sorry, _what_ is so?

> At least, with window-local values the Flycheck navigation in the given buffer
> will be confined within the selected window and won't affect other navigations
> in other windows.

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.

> So continuing a navigation in other buffers/windows won't
> continue Flychecking of an unrelated buffer.  So Flychecking should not set
> the global value of next-error-last-buffer.

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?

Does every navigational window get a second, dedicated window for its 
locations? Often, we don't have many windows to spare.

> > Hence my proposal to equate the value nil of next-error-last-buffer with
> > "use the current buffer".
>
> What/who and how would nullify/reset next-error-last-buffer?

A new command. Or maybe a special value of the prefix argument to 
`next-error'? M-0 C-x `, maybe?

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.