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

Previous Next

Package: emacs;

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


Message #53 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: Fri, 29 Jan 2016 01:59:45 +0200
> Maybe it's a good idea, but I'm not sure how to enforce something like
> that, to be able to rely on it. And a small arrow in one window is not
> a great indicator anyway.

A good indication could be provided by a new global minor mode
‘global-next-error-minor-mode’ showing in the mode line
the currently active navigation, and allowing switching
to another navigation.

> The rule#1, as written, also poorly interacts with Flycheck-like use
> cases. Are you going to comment on that part discussion?

Flycheck provides its own keybinding ‘C-c ! n’ for ‘flycheck-next-error’,
so really there is no problem.

A real problem is when a navigational buffer does exist, but it's hidden.
IIUC, due to this problem you reverted next-error integration in xref, right?

> We can also realize that the rule #1 is an attempt to do the following: if
> next-error-last-buffer is no longer visible, try to pick a navigational
> buffer among the currently visible ones.

You mean next-error-last-buffer is no longer visible _on the selected frame_?

> However, the rule tries to limit the number of visible navigational buffer
> to one, and aborts otherwise. I think that's because it doesn't know any
> better way to distinguish between navigational buffers and plain
> file-visiting buffers that have next-error-function set locally
> (navigational buffers can also be file-visiting, as in the cases of
> change-log-mode and diff-mode). The new variable that I proposed
> would help.

Yes, this is because it's hard to find a better way, and I'm not sure
how next-error-function-nonlocal could help, because sometimes a navigation
might visit another non-file navigational buffer, e.g. multi-occur
visiting a *compilation* 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.