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

[Dmitry Gutov]

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

> > Yes. This was my appeal to keep the existing integration of xref with
> > next-error-function. Eli disagreed.
> >
> > What can we gather from that?
>
> I could gather only that we need to support this case in next-error
> before enabling next-error in xref.

So I stated the same as you, Eli disagreed, and we're going to conclude 
that you are right? Good job.

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

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

Seem like lots of complexity for nothing.

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

> > > Isn't it so that the user will remember which navigation displayed
> > > a given window?
> >
> > Sorry, _what_ is so?
>
> The users hopefully remember which navigation displayed a given window.

Did your previous sentence make sense? Did you actually mean "Won't 
users remember..."?

And to answer the question, I don't think so. At least, not every time.

It seems kind of pointless to answer an observation about added 
complexity with "won't users remember everything?", don't you think?

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

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

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

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

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