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

[Juri Linkov <juri@linkov.net>]

> On that subject: why did we make next-error-last-buffer always buffer-local?

next-error-last-buffer is buffer-local to keep the reference to the
parent buffer used to navigate to the current buffer, so the next call of
next-buffer will use the same parent buffer to continue navigation from it.

This works well in most cases except the case of xref buffers.
Below is the explanation for code from next-error with added remarks:

(defun next-error (&optional arg reset)
  (let ((buffer (next-error-find-buffer)))
    (when buffer
      (with-current-buffer buffer

Here the current buffer is *xref*

        (funcall next-error-function (prefix-numeric-value arg) reset)

next-error-function should navigate from *xref* to another buffer
and change the current-buffer to the navigated buffer, e.g. ChangeLog.1.
This works fine in most cases, for example when next-error-function is
compilation-next-error-function, but fails when next-error-function is
xref--next-error-function that switches to ChangeLog.1, but doesn't set
the value current-buffer to ChangeLog.1.

        (setq next-error-last-buffer buffer)

In normal cases this sets buffer-local next-error-last-buffer in the
navigated buffer, e.g. ChangeLog.1 that should be the current buffer.
But since xref--next-error-function doesn't set the right current buffer
to ChangeLog.1, this sets buffer-local next-error-last-buffer in the wrong
buffer, i.e. in *xref*.  IOW, the value returned from (current-buffer)
is wrong here after xref--next-error-function call.

So the question is: in xref--next-error-function can we use code similar
to what is used in compilation-next-error-function that works without problems?