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

[Dmitry Gutov]

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.