|
From: | Dmitry Gutov |
Subject: | 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 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |