From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 20489@debbugs.gnu.org
Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason
Date: Wed, 28 Feb 2018 04:13:54 +0200 [thread overview]
Message-ID: <de30f4c8-ecb8-47d3-5af4-c8395337f984@yandex.ru> (raw)
In-Reply-To: <87efl6smxb.fsf@mail.linkov.net>
On 2/27/18 11:16 PM, Juri Linkov wrote:
>> 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.
Thank you for the reminder. Looking at the previous discussion, I wasn't
fond of this design back then, and still think it's largely unnecessary
complexity (it introduces implicit state, and in the situations that it
can be useful in, the user will have to remember which windows came from
which navigation).
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.
This way, someone would also be able to implement window-local
navigation relationship instead of buffer-local (you've mentioned this
option before).
> 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.
If that's something next-error-function must do, let's document it
better. Right now it only says "Function to use to find the next error
in the current buffer" (how does one "find" an error?) and describes
input arguments, but not the return value (which is luckily unused) or
which buffer must be current, or which window selected at the end.
> 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.
I see.
> 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?
You probably mean compilation-goto-locus (it contains the navigation
part), but even so, it's not easy to tell which part you mean (the
function does more than one would expect).
In short, adapting that code is kind of difficult, but hopefully I found
and fixed the problem in xref directly in
11c58c4fc495ea4f7bff52ca077fd3e4382aa900.
next prev parent reply other threads:[~2018-02-28 2:13 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-02 23:17 bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Dmitry Gutov
2015-05-03 5:49 ` Stefan Monnier
2015-05-03 12:56 ` Dmitry Gutov
2015-05-04 22:03 ` Ted Zlatanov
2015-05-04 22:22 ` Dmitry Gutov
2015-05-04 22:33 ` Ted Zlatanov
2015-05-05 15:05 ` Dmitry Gutov
2015-05-05 15:15 ` Ted Zlatanov
2016-01-24 21:10 ` Juri Linkov
2016-01-25 6:23 ` Dmitry Gutov
2016-01-25 21:55 ` Juri Linkov
2016-01-25 23:36 ` Dmitry Gutov
2016-01-27 0:57 ` Juri Linkov
2016-01-27 2:43 ` Dmitry Gutov
2016-01-27 22:57 ` Juri Linkov
2016-01-27 23:28 ` Dmitry Gutov
2016-01-28 23:59 ` Juri Linkov
2016-01-29 0:35 ` Dmitry Gutov
2016-01-29 23:44 ` Juri Linkov
2016-01-30 0:57 ` Dmitry Gutov
2016-01-30 23:43 ` Juri Linkov
2016-01-31 0:39 ` Dmitry Gutov
2016-01-31 21:57 ` Juri Linkov
2016-01-31 22:38 ` Dmitry Gutov
2016-02-02 0:44 ` Juri Linkov
2016-02-02 1:40 ` Dmitry Gutov
2016-02-03 0:35 ` Juri Linkov
2016-02-04 1:00 ` Dmitry Gutov
2016-02-22 0:01 ` Dmitry Gutov
2016-02-22 17:22 ` Eli Zaretskii
2016-02-22 17:30 ` Dmitry Gutov
2016-02-22 17:39 ` Eli Zaretskii
2016-02-22 18:09 ` Dmitry Gutov
2016-02-22 18:11 ` Dmitry Gutov
2016-02-22 19:07 ` Eli Zaretskii
2016-02-27 10:14 ` Eli Zaretskii
2016-02-29 3:15 ` Dmitry Gutov
2016-02-29 16:23 ` Eli Zaretskii
2016-02-29 23:30 ` Dmitry Gutov
2017-11-06 21:53 ` Juri Linkov
2018-02-15 22:16 ` Juri Linkov
2018-02-27 1:21 ` Dmitry Gutov
2018-02-27 1:54 ` Dmitry Gutov
2018-02-27 18:07 ` Dmitry Gutov
2018-02-27 21:16 ` Juri Linkov
2018-02-28 2:13 ` Dmitry Gutov [this message]
2018-02-28 21:17 ` Juri Linkov
2018-03-02 1:19 ` Dmitry Gutov
2018-03-06 22:17 ` Juri Linkov
2018-03-07 14:11 ` Dmitry Gutov
2018-03-07 21:11 ` Juri Linkov
2018-03-12 22:08 ` Dmitry Gutov
2018-02-28 21:25 ` Juri Linkov
2018-03-01 22:58 ` Juri Linkov
2018-03-02 1:26 ` Dmitry Gutov
2018-03-06 22:25 ` Juri Linkov
2018-03-07 14:08 ` Dmitry Gutov
2018-03-07 21:03 ` Juri Linkov
2018-02-28 21:32 ` Juri Linkov
2018-03-02 0:54 ` Dmitry Gutov
2018-03-01 23:04 ` Juri Linkov
2018-03-02 1:30 ` Dmitry Gutov
2018-02-28 17:33 ` Richard Stallman
2018-02-21 21:30 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=de30f4c8-ecb8-47d3-5af4-c8395337f984@yandex.ru \
--to=dgutov@yandex.ru \
--cc=20489@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.