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

Previous Next

Full log

Message #50 received at 20489 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
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: Thu, 28 Jan 2016 02:28:01 +0300

On 01/28/2016 01:57 AM, Juri Linkov wrote:

> You can see an arrow indication in the left fringe of the navigational window
> that points to the location of the current file displayed in an adjacent window.

That's only true of compilation-mode and its derivatives. It's not a 
part of next-error-function contract (again, change-log-next-error does 
nothing of the sort; diff-next-error doesn't either).

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.

> I just posted an IDE-like layout to emacs-devel, and it demonstrates that the
> current rule#1 in next-error-find-buffer is the right thing to do in this
> scenario: after switching from e.g. *grep* to *xref* in the bottom window,
> next-error will continue navigation from the visible navigation buffer.
> So no changes are required in this case.

What case? We're not going to introduce IDE-like layout as the 
mandatory, or the default, behavior.

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

Because if you're going to disregard it, we might as well stop talking 
right now: any acceptable proposal, as far as I'm concerned, handles 
that case.

> The problem is in the cases that this rule doesn't support, i.e.
> (< (length window-buffers) 1) and (> (length window-buffers) 1)
> We need to find a way to handle these cases as well.

Yes: remove that check, for example.

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.

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.

> No clicking at all, I don't use the mouse :)

Lots of pressing the buttons, then. Which is what I meant.

Previous Next

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