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

Previous Next

Full log

Message #41 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: Wed, 27 Jan 2016 02:57:30 +0200

> How does it really help? You've navigated from *grep*, to that buffer A,
> then did that from *compilation*, and then you can't continue jumping to
> next *grep* occurrences from that buffer.

I suppose that navigation from every navigational window displays its targets
in own dedicated window that will be associated with its “parent” window.
So e.g. after navigating from *grep* to window A, and from *compilation*
to window B, next-error invoked from windows A or B will continue
the right navigation.

> We can fix xref, but not every next-error-function uses the same window,
> and that's not codified in this variable's docstring. change-log-next-error
> doesn't.

If some next-error-function doesn't use the same window, still there is
no problem because its displayed window will continue the last navigation
visited in that window.

>>> Suppose I called M-x compile (or, better yet, M-x grep), navigated to some
>>> file buffer from it and then see that it has some linter errors highlighed
>>> by Flycheck. So I want to use the current buffer's next-error-function now,
>>> and jump between linter warnings using next/previous-error. How do I do
>>> that? IIU your plan correctly, the current window-local
>>> next-error-last-buffer value will continue pointing at the Grep buffer,
>>> even if I bury it.
>>
>> What if you have two navigations in the same buffer, and both are
>> without a navigation window that you can't bury?
>
> I don't follow. The above was an attempt to point out an hole in your
> plan. I'm not sure you can refute that with a "what if" counter-example.

This adds another problematic case to consider, but we could avoid it
by always requiring creation of a navigation buffer, possibly hidden
when necessary.  (As for your point about a hole, I already addressed it
below - that requires unburing a navigation buffer that you want switch to).

>>> - Some indicator that a given buffer's next-error-function points to other
>>> buffer (then, if you're in a different buffer, that other buffer is still
>>> relevant). Like a buffer-local variable called, for example,
>>> next-error-function-nonlocal.
>>
>> Do you mean to bind a navigation buffer with navigated target buffers/windows?
>
> I mean to ask compilation-mode (as well as other similar modes) to
> (setq-local next-error-function-nonlocal t), in addition to setting
> next-error-function and next-error-last-buffer.

How this could help to point to other buffer?

>>> - A command (or several) to switch between the plausible candidates for
>>> next-error-last-buffer. Maybe just have a single command that uses
>>> read-buffer with a predicate checking the aforementioned variable and an
>>> extra option that means "just use the current buffer".
>>
>> This would be too complicated to use.
>
> Why complicated? It would just be a way to choose the source of errors to
> follow. You'd also be able to do that by clicking on an error, or pressing
> RET, in the "nonlocal" navigation buffers.

I think it would be more WYSIWYG first to switch to the navigation buffer,
and then to click on an error, or press RET.

> The main point, however, which you might not agree with, is to make
> next-error-last-buffer global.

I prefer this precedence:
1. window-local next-error-last-buffer
2. buffer-local next-error-last-buffer
3. global next-error-last-buffer

>>> - Ignore next-error-last-buffer's visibility. Or make it frame-local, to
>>> account for your scenario as well (but that would bring extra complexity:
>>> some people use use frames like almost separate applications, and other can
>>> use frames instead of windows, and display them side-by-side).
>>
>> Buffers are displayed in windows, so better to bind them to windows.
>
> Making next-error-last-buffer window-local feels clunkier to me: there
> would be no indication that a given window is following *Compilation*, for
> example. And up until now, next-error worked more or less in
> a global fashion.

Are you hinting that currently there is such indication in the form of
navigation buffer's window displayed in the same frame (rule#1 in
next-error-find-buffer)?

I proposed window-local next-error-last-buffer only because you had
some problems with this rule using in xref.

>> I remember the original idea was to always continue the same navigation
>> that displayed a given target buffer/window, so switching to another
>> navigation in the same window could be achieved by explicitly navigating
>> to another result from another navigation, e.g. when current navigation
>> was from *compilation* then switching to *grep* buffer and typing M-n
>> for the next grep hit in the same file buffer.
>
> How will you "switch" to the next-error-function set locally by Flycheck in
> the current file-visiting buffer?

By restarting Flycheck?

> How will you switch between Grep and Compilation if they display a location
> in the same buffer (and window)? Won't the desired navigation buffer have
> to be visible? So you'd have to select some window, switch to that buffer
> in it, and then click or press RET on some error?

Yes.

> Using a command to switch between next-error-last-buffer candidates seems
> much quicker.

In case of Flycheck, there will be no next-error-last-buffer, no?

Previous Next

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