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

Previous Next

Full log

Message #62 received at 20489 <at> debbugs.gnu.org (full text, mbox):

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

On 01/30/2016 02:44 AM, Juri Linkov wrote:

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

Fair enough. But the complaint about memorizing different key bindings 
still stands.

>>> 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?

Why is that a problem? Depending on the approach, we either keep using 
it, or switch to the visible one.

>> 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?

You really should ask Eli what exactly he meant there, I'm just 
guessing. I didn't want to keep inquiring at that point. Eli said 
disable, so I disabled.

But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the 
configuration with three buffers with next-error-function set visible. 
Hide the current last-buffer: nothing changes, `next-error' continues 
working as it did. Hide the next one: and suddenly, `next-error' starts 
behaving differently.

The user is expected to understand too much.

>> 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.

So? It's you who's advocating to stop using the non-visible 
last-buffer's. My first choice is to only switch next-error-last-buffer 
when the user requests this explicitly.

On the other hand, if we choose the semantics "not visible => bad 
last-buffer", that would be understandable, too.

I don't see why you consider the case "multi-occur references 
compilation" to be more special than others. It seems no different from 
"both grep and compilation are visible".

> 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.

Your proposal _complicates_ the current state, making it more of a 
problem. If the global value of next-error-last-buffer is used 
consistently, at least the current state is easier to remember.

I'm also not a big fan of window-local semantics here, personally.

> This issue is real,
> but orthogonal to the subject of bug#20489.

Would you like me to rename the subject to something? The actual problem 
is that `next-error' exhibits surprising behavior, and doesn't properly 
support `next-error-function' being set in file-visiting buffers, which 
is a common situation these days.

Since filing this bug, I've somewhat warmed up to using buffer 
visibility as a condition to choose next-error-last-buffer.

Previous Next

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