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

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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: Tue, 02 Feb 2016 02:44:42 +0200

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

I could gather only that we need to support this case in next-error
before enabling next-error in xref.

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

The primary question is not how many users asked for it many years ago,
but how many users are using it now.

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

Obviously, get-mru-“next-error”-window, i.e. a combination of both.

> And, again, this ignores the Flycheck case.

Alas, this means we have to trade visibility of next-error-last-buffer
for window-local values.

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

The users hopefully remember which navigation displayed a given window.

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

C-x ` in any window will use the global value, i.e. the last navigation.

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

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

Why only “nonlocal”?

Previous Next

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