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

[Dmitry Gutov]

On 02/03/2016 03:35 AM, Juri Linkov wrote:

> > 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 ;)

Apparently, you have no data at all, then. As a user, I don't care about 
it either way.

As a _developer_, I might remove it. Which is what should be done if a 
feature can't be implemented in a sane way without trampling on user 
experience in other aspects.

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

This will almost always default to the current window if you write 
Elisp, and have global-flycheck-mode enabled.

Can't you give a full, constructive proposal, instead of giving pieces 
that are easy to poke holes in?

> > > > 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.

You haven't answered the "what" question. But assuming I managed to 
guess your meaning...

How come window-local values are any better? If "next-error-last-buffer 
is the current buffer" is the current buffer when the variable is stored 
globally, it will be the window-local value when the variable is stored 
window-locally. Unless the buffer is not visible, in which case the 
question is moot.

> > > > 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.

Then you are contradicting yourself.

> I see no reason not to use this behavior by default.

It undermines your proposal: either you have a separate dedicated window 
for each navigational buffer to show locations in, or the navigational 
buffers trample on each other's windows when they visit the same files.

Which creates the same problem you had, except in certain specific 
circumstances. But those circumstances are not *that* rare. This will 
make the behavior less consistent and increase user confusion.

> 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.

*compilation* jumps to foo.el, then *grep* jumps to foo.el. Both use the 
same window (the default behavior), and both have an arrow in their 
buffers indicating that foo.el's window is "theirs". However, the last 
navigational buffer wins.

> > 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.

I don't see how that solves anything.