[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: |
Sat, 30 Jan 2016 03:57:57 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 |
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.
- 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/25
- 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 <=
- 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, 2016/01/30
- 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