[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer wi
From: |
Dmitry Gutov |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 |
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".
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, (continued)
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Dmitry Gutov, 2016/01/25
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Juri Linkov, 2016/01/26
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Dmitry Gutov, 2016/01/26
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Juri Linkov, 2016/01/27
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Dmitry Gutov, 2016/01/27
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Juri Linkov, 2016/01/28
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Dmitry Gutov, 2016/01/28
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Juri Linkov, 2016/01/29
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Dmitry Gutov, 2016/01/29
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Juri Linkov, 2016/01/30
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason,
Dmitry Gutov <=
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Juri Linkov, 2016/01/31
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Dmitry Gutov, 2016/01/31