GNU bug report logs -
#20489
25.0.50; next-error-find-buffer chooses non-current buffer without good reason
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Sat, 2 May 2015 23:19:01 UTC
Severity: normal
Found in version 25.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>> The link to the discussion is here:
>> http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00614.html
>> where you can see the case that we need to support.
>
> In this scenario, it seems like you could have benefited from
> next-error-last-buffer value being frame-local instead (maybe implemented
> as a frame parameter?).
A frame might contain more pairs of navigational/target windows,
e.g. a window with *grep* output, and a file buffer visited from *grep*;
a window with *Occur*, and another place in the same file buffer
but visited from *Occur*, etc.
So frame-local is not of help here, whereas window-local is,
provided a navigational window (like *grep*/*compilation*)
always displays target buffers in another dedicated window.
As I see this is not what xref currently does: navigating in it
jumps between many different windows that is very inconvenient,
but this can be easily fixed to work the sane way as *grep*
or *compilation* already works.
>> Now that we have window-local variables, it's possible to support
>> this case in a proper way. Instead of checking if a buffer visible
>> in the current frame, we should check the window-local value of
>> next-error-last-buffer. Thus invoking next-error in the window
>> with the source buffer will continue navigation using the right value
>> of next-error-last-buffer that navigated to its previous occurrence.
>
> How do linting minor modes (like Flycheck or Flymake) fit into this?
Does Flycheck or Flymake display a navigation window with a list of results?
If not, then this is a new case that we need to support as well.
> 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?
> Basically, I want to have two at least somewhat guessable sequences of
> actions that would let the user choose which buffer to use for its
> next-error-function.
>
> As discussed in this issue, the best way to do that seems to require:
>
> - 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?
> - 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.
> - 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.
> WDYT?
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.
This bug report was last modified 7 years and 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.