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

Previous Next

Full log

View this message in rfc822 format

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

Hi Juri,

Thank you for the reply.

But having had time to consider this issue, I think there are benefits 
to how it currently works. For instance, if I want to switch from a 
Compilation's buffer next-error-function to the current file buffer's 
one, I just need to bury Compilation (doing the reverse might be harder, 
however). If we change this logic, we should make sure not to make 
anything worse.

On 01/25/2016 12:10 AM, Juri Linkov wrote:

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

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

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.

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.

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

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

WDYT?

Previous Next

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