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

From: Juri Linkov <[email-masked]>
Date: Sat, 30 Jan 2016 01:44:07 +0200

> Do you expect me to repeatedly type `C-c ! n' to move across errors in the
> current buffer? It's not like it's inconvenient or
> anything. next-error-function was added exactly so that the user doesn't
> have to learn a bunch of different key bindings for basically the
> same thing.

Not repeatedly, it's enough to type is only once, and subsequent invocations
of next-error will pick up a new navigation.

>> A real problem is when a navigational buffer does exist, but it's hidden.
>> IIUC, due to this problem you reverted next-error integration in xref, right?
>
> No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html
>
> See the first sentence there.

I reread it every time you reference it, but it adds nothing to the discussion.
Could you provide more details about this problem.  I imagine you meant the case
when *xref* is hidden, but *compilation* is visible.  Is it so?  What are the
preconditions for this situation to occur?

>> Yes, this is because it's hard to find a better way, and I'm not sure
>> how next-error-function-nonlocal could help, because sometimes a navigation
>> might visit another non-file navigational buffer, e.g. multi-occur
>> visiting a *compilation* buffer.
>
> What is the exact problem you have in mind there?
>
> When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps
> referring to *multi-occur*.

But after you hide *compilation*, *multi-occur* will kick in.
This is why I proposed to use window-local values, and your counter-arguments
against it (indication/switching) apply to the already used global value
of next-error-last-buffer as well: its current state is not discoverable
and it's not easy to switch to another navigation.  This issue is real,
but orthogonal to the subject of bug#20489.