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

[Dmitry Gutov]

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?

Yes.

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.