[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
bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason
Fri, 2 Mar 2018 03:19:01 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0
On 2/28/18 11:17 PM, Juri Linkov wrote:
Anyway, I've fixed the current problem (see below), so this is a matter of
opinion. If you still consider this feature to be important, I think
ideally we'd abstract it away behind a new -function variable as well.
Please clarify what do you have in mind. In what place in code such
function could be called?
Any place that contains
(setq next-error-last-buffer buffer)
(setq-default next-error-last-buffer buffer)
now, would instead call
(funcall next-error-save-last-buffer-function target-buf target-win)
This way, someone would also be able to implement window-local navigation
relationship instead of buffer-local (you've mentioned this option before).
Window-local navigation could be implemented by something like below.
But maybe window-local specific code in next-error and next-error-internal
could be abstracted away in a function that you proposed above?
next-error-save-last-buffer-function and next-error-find-buffer-function
would have to be in sync (we'd have to somehow make sure the user will
have to try hard to set them to incompatible values, at least if they do
that via the Customize interface).
Further, I think next-error-find-buffer-function will also have to
encompass the item 2 in next-error-find-buffer, so that the alternative
could supply the window-local value instead.
Anyway, I'd really like to put a pin in both buffer-local and
window-local values for now, because they both complicate the picture.
Instead, could we address bug#30674 first? Personally, moving between
errors and warnings in the current file using next/previous-error feels
a lot more useful.