[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer wi

From: Dmitry Gutov
Subject: 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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]