[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer wi

From: Juri Linkov
Subject: 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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]