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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Ted Zlatanov <tzz <at> lifelogs.com>
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: Tue, 5 May 2015 18:05:29 +0300

On 05/05/2015 01:33 AM, Ted Zlatanov wrote:

> Some history: I actually, long ago when `next-error' turned into a
> navigation facility, we[1] had the idea of "meta next-error" which would
> navigate one level higher than local. That would have made this whole
> discussion, including rankings by priority, moot by simply saying "to
> navigate between files (compile, grep) you use `meta-next-error' or
> whatever it's called. to navigate inside file locations, use
> `next-error'."

Thanks for the link.

That would've been an improvement, but it wouldn't solve a related 
problem: when *grep* buffer was created after a *compile* one, how to 
get back to using *compile*'s list of errors.

> Perhaps you are interested in adapting that code instead of hacking on
> the current scheme?  Or should I retry implementing it?  9 years late is
> not too bad, right? :)

9 years is just right, but I'm not sure how much of that implementation 
we would reuse. It's also not obvious me how to move to the next file, 
if you only have a next-error-function.

M-g M-f/b could switch between next-error-last-buffer values, though. 
Especially if they're organized in a ring, like Helmut suggested. That 
will require an update to any Compilation-like mode.

Previous Next

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