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: Fri, 29 Jan 2016 03:35:19 +0300

On 01/29/2016 02:59 AM, Juri Linkov wrote:

> ...and allowing switching
> to another navigation.

Are you coming around to my suggestion now?

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

That's basically giving up.

Do you expect me to repeatedly type `C-c ! n' to move across errors in 
the current buffer? It's not like it's inconvenient or anything. 
next-error-function was added exactly so that the user doesn't have to 
learn a bunch of different key bindings for basically the same thing.

There's also e.g. js2-mode, which doesn't have a custom key binding for 
this. And probably other modes that I just don't know about.

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

No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html

See the first sentence there.

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

I don't really care either way. This question doesn't seem to add any 
big constraints on the final solution.

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

What is the exact problem you have in mind there?

When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps 
referring to *multi-occur*.

Previous Next

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