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 #47 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: Thu, 28 Jan 2016 00:57:31 +0200
>> So e.g. after navigating from *grep* to window A, and from *compilation*
>> to window B, next-error invoked from windows A or B will continue
>> the right navigation.
>
> Suppose you've did that, then turned left to look out of the window for
> half a minute, then looked back at Emacs. How are you going to predict what
> M-x next-error will do?

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.

> But my first choice is to not rely on buffer visibility at all, and simply
> follow the current global next-error-last-buffer value, as well as provide
> an easy way to switch to a different one.

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.

>> I proposed window-local next-error-last-buffer only because you had
>> some problems with this rule using in xref.
>
> Yes, I did. But IIUC, Eli had more of a problem with the
>
> (if (eq (length window-buffers) 1)
>
> part of that rule. The commit that disabled next-error integration in xref
> has a link to that discussion in its message.

The rule (if (eq (length window-buffers) 1) itself is not a problem.

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.

>>> How will you switch between Grep and Compilation if they display a location
>>> in the same buffer (and window)? Won't the desired navigation buffer have
>>> to be visible? So you'd have to select some window, switch to that buffer
>>> in it, and then click or press RET on some error?
>>
>> Yes.
>
> Lots of clicking.

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




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.