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: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
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, 31 Jan 2016 03:39:35 +0300

On 01/31/2016 02:43 AM, Juri Linkov wrote:

> I believe Eli meant this case because it's hard to imagine another one.
> So we have to find a solution for this case.

Let's not base the rest of the discussion on a guess, shall we?

In the message above, he was replying to my message, where I said: "On 
the other hand, while *xref* is visible, `next-error' will keep working 
for its results".

I can hardly imagine that in his counter-example, *xref* is hidden.

> By setting a window-local value of next-error-last-buffer in the
> selected window, we can continue the xref-navigation even when
> *compilation* is visible in an adjacent window.

Yes. But we _only_ continue it from the same window, which I do not 
believe to be a good goal.

On the other hand, if we just use the global next-error-last-buffer 
value, we'll just as well "continue the xref-navigation even when 
*compilation* is visivle in an adjacent window".

>> 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.
>
> When the number of next-error-function windows is more than one, then
> there's a dilemma which one to use.

Let's use the last one. That would definitely simplify things.

On the other hand, if we assign and read next-error-last-buffer value 
via two accessor functions, anyone would be able to change the locality 
of that value. You'd be able to use advice, to store it window-locally.

>> 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.
>
> But it allows the user to continue a paused navigation in another window
> in another frame, thus having several simultaneously active navigations
> in different windows.

If the "previous" navigation buffer is visible, you can also continue 
navigation by going to it, and using one of the links there.

If it's not visible, it would make remembering which window belongs to 
which navigation, even more difficult.

> What happens when two features set `next-error-function' at the same time?
> I guess the latest wins, so there is no problem no matter if using
> visibility of next-error-last-buffer or window-local values.

Yes, if next-error-function is set locally in a file buffer, we can only 
see the last value.

But rather than "no problem", I'd say that neither approach to 
visibility of next-error-last-buffer solves the Flycheck problem.

>> Since filing this bug, I've somewhat warmed up to using buffer visibility
>> as a condition to choose next-error-last-buffer.
>
> Visibility of next-error-last-buffer is not suitable for navigations
> without a navigational buffer.

Hence my proposal to equate the value nil of next-error-last-buffer with 
"use the current buffer".

Previous Next

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