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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Sun, 3 May 2015 15:56:11 +0300

On 05/03/2015 08:49 AM, Stefan Monnier wrote:

> IIRC this had something to do with hitting C-x ` to jump through the
> various elements of a *compile* or *grep* buffer, where some of those
> C-x ` may end up jumping to a buffer that itself has
> next-error-function set.

That's what I guessed, then. It doesn't solve the problem completely 
anyway. If the *grep* buffer is buried or displayed in a different frame 
(which is arguably is the best case for using C-x `), C-x ` might open a 
buffer with next-error-function set, and it will overtake, if it's the 
only one such in the currently visible frame. There's no easy way to get 
back to Grep's next-error-function either.

Why don't we prioritize, in next-error-find-buffer, 
next-error-last-buffer over everything else (change the order to 2 3 1 4 
5 6)?

And then add some way to change next-error-last-buffer programmatically 
(choosing between the current buffer, if it has next-error-function set, 
and all other buffers with next-error-function set and buffer-file-name 
nil; defaulting to the current one).

M-0 C-x ` (like suggested by Vitaly) might be OK, to change the used 
buffer and move to the next error in one step (and similarly in 
previous-error). But that hijacks the meaning of 0 argument.

Previous Next

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