[Top][All Lists]

[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: Fri, 29 Jan 2016 03:35:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/29/2016 02:59 AM, Juri Linkov wrote:

...and allowing switching
to another navigation.

Are you coming around to my suggestion now?

The rule#1, as written, also poorly interacts with Flycheck-like use
cases. Are you going to comment on that part discussion?

Flycheck provides its own keybinding ‘C-c ! n’ for ‘flycheck-next-error’,
so really there is no problem.

That's basically giving up.

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.

There's also e.g. js2-mode, which doesn't have a custom key binding for this. And probably other modes that I just don't know about.

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.

We can also realize that the rule #1 is an attempt to do the following: if
next-error-last-buffer is no longer visible, try to pick a navigational
buffer among the currently visible ones.

You mean next-error-last-buffer is no longer visible _on the selected frame_?

I don't really care either way. This question doesn't seem to add any big constraints on the final solution.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]