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

Previous Next

Full log

Message #74 received at 20489 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 20489 <at> debbugs.gnu.org
Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current
 buffer without good reason
Date: Mon, 1 Feb 2016 01:38:43 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.