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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 20489 <at> debbugs.gnu.org
Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason
Date: Sun, 24 Jan 2016 23:10:30 +0200

> - If a buffer visible in the current frame has next-error-function set,
>   *and* if there's only one such buffer, use it.
>
> - If next-error-last-buffer has it set, use that.
>
> Othewise, if both of the above fail,
>
> - If the current buffer has next-error-function set, use it.
>
> Apparently, this peculiarity has been there for 10.5 years now,
> introduced in 03e75c7e0 by Juri Linkov. But there's no bug reference, nor
> a link to a discussion.

Sorry, I missed this bug report and regret that it caused you to revert
xref's next-error-function integration.

The link to the discussion is here:
http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00614.html
where you can see the case that we need to support.

Now that we have window-local variables, it's possible to support
this case in a proper way.  Instead of checking if a buffer visible
in the current frame, we should check the window-local value of
next-error-last-buffer.  Thus invoking next-error in the window
with the source buffer will continue navigation using the right value
of next-error-last-buffer that navigated to its previous occurrence.

Thus, the steps will be the following:

1. If window-local next-error-last-buffer is an acceptable buffer, use that.
2. If next-error-last-buffer is an acceptable buffer, use that.
3. If the current buffer is acceptable, choose it.
4. Look for any acceptable buffer.
5. Use the current buffer as a last resort if it qualifies, even despite AVOID-CURRENT.
6. Give up.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.