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, 31 Jan 2016 23:57:33 +0200

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

Clearly, this describes a successful case as opposed to the problematic one
where *xref* is hidden that evidently needs fixing.

>> 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
> visible in an adjacent window".

And lose the support for the case of simultaneously active navigations
in different windows/frames.

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

Indeed, using (get-mru-window 'visible t t) makes sense.

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

Customizable next-error-find-buffer?  Maybe, if we'll fail to find
a reasonable default.

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

Isn't it so that the user will remember which navigation displayed
a given window?

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

At least, with window-local values the Flycheck navigation in the given buffer
will be confined within the selected window and won't affect other navigations
in other windows.  So continuing a navigation in other buffers/windows won't
continue Flychecking of an unrelated buffer.  So Flychecking should not set
the global value of next-error-last-buffer.

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

What/who and how would nullify/reset 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.