[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: |
Juri Linkov |
Subject: |
bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason |
Date: |
Sat, 30 Jan 2016 01:44:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) |
> Do you expect me to repeatedly type `C-c ! n' to move across errors in the
> current buffer? It's not like it's inconvenient or
> anything. next-error-function was added exactly so that the user doesn't
> have to learn a bunch of different key bindings for basically the
> same thing.
Not repeatedly, it's enough to type is only once, and subsequent invocations
of next-error will pick up a new navigation.
>> 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?
>
> 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?
>> Yes, this is because it's hard to find a better way, and I'm not sure
>> how next-error-function-nonlocal could help, because sometimes a navigation
>> might visit another non-file navigational buffer, e.g. multi-occur
>> visiting a *compilation* buffer.
>
> What is the exact problem you have in mind there?
>
> 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.
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. This issue is real,
but orthogonal to the subject of bug#20489.
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, Juri Linkov, 2016/01/24
- 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 <=
- 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, 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