bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Thu, 28 Jan 2016 02:28:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/28/2016 01:57 AM, Juri Linkov wrote:

You can see an arrow indication in the left fringe of the navigational window
that points to the location of the current file displayed in an adjacent window.

That's only true of compilation-mode and its derivatives. It's not a part of next-error-function contract (again, change-log-next-error does nothing of the sort; diff-next-error doesn't either).

Maybe it's a good idea, but I'm not sure how to enforce something like that, to be able to rely on it. And a small arrow in one window is not a great indicator anyway.

I just posted an IDE-like layout to emacs-devel, and it demonstrates that the
current rule#1 in next-error-find-buffer is the right thing to do in this
scenario: after switching from e.g. *grep* to *xref* in the bottom window,
next-error will continue navigation from the visible navigation buffer.
So no changes are required in this case.

What case? We're not going to introduce IDE-like layout as the mandatory, or the default, behavior.

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

Because if you're going to disregard it, we might as well stop talking right now: any acceptable proposal, as far as I'm concerned, handles that case.

The problem is in the cases that this rule doesn't support, i.e.
(< (length window-buffers) 1) and (> (length window-buffers) 1)
We need to find a way to handle these cases as well.

Yes: remove that check, for example.

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.

However, the rule tries to limit the number of visible navigational buffer to one, and aborts otherwise. I think that's because it doesn't know any better way to distinguish between navigational buffers and plain file-visiting buffers that have next-error-function set locally (navigational buffers can also be file-visiting, as in the cases of change-log-mode and diff-mode). The new variable that I proposed would help.

No clicking at all, I don't use the mouse :)

Lots of pressing the buttons, then. Which is what I meant.





reply via email to

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