[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: Thu, 4 Feb 2016 04:00:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 02/03/2016 03:35 AM, Juri Linkov wrote:

You're welcome to poll, but so far we only have the data about
a single user.

Yes, a single user who wants to remove it ;)

Apparently, you have no data at all, then. As a user, I don't care about it either way.

As a _developer_, I might remove it. Which is what should be done if a feature can't be implemented in a sane way without trampling on user experience in other aspects.

Just traverse all windows in the order of recency until finding a window
with next-error-function.

This will almost always default to the current window if you write Elisp, and have global-flycheck-mode enabled.

Can't you give a full, constructive proposal, instead of giving pieces that are easy to poke holes in?

And, again, this ignores the Flycheck case.

Alas, this means we have to trade visibility of next-error-last-buffer
for window-local values.

What means? And why?

In case of Flycheck it's next-error-last-buffer is the current buffer
and is always visible.

You haven't answered the "what" question. But assuming I managed to guess your meaning...

How come window-local values are any better? If "next-error-last-buffer is the current buffer" is the current buffer when the variable is stored globally, it will be the window-local value when the variable is stored window-locally. Unless the buffer is not visible, in which case the question is moot.

Suppose I use flycheck-next-error in foo.el. And I have a *grep* buffer
visible, and I jumped to bar.el from it. And the next error in *grep* is in
foo.el. What happens when I, having returned to bar.el's window, call
next-error again? Does it jump to foo.el's window? Does it display foo.el
in the window where bar.el previously was?

It will display foo.el in the window where bar.el previously was.

Aren't you at all worried about running out of windows (and not being
allowed to split them)? In our last discussion with Martin, he expressed
concern that some users use one window per frame. In this scenario, you'll
need at least 3. And with two navigational buffers visible, the number of
necessary windows will grow to 5.

I meant reusing an existing window with a file buffer, not creating a new

Then you are contradicting yourself.

I see no reason not to use this behavior by default.

It undermines your proposal: either you have a separate dedicated window for each navigational buffer to show locations in, or the navigational buffers trample on each other's windows when they visit the same files.

Which creates the same problem you had, except in certain specific circumstances. But those circumstances are not *that* rare. This will make the behavior less consistent and increase user confusion.

What I see is that *compilation* always reuses another window to not replace
the navigational *compilation* buffer with a file buffer.  Do you know
under what circumstances this behavior might fail.

*compilation* jumps to foo.el, then *grep* jumps to foo.el. Both use the same window (the default behavior), and both have an arrow in their buffers indicating that foo.el's window is "theirs". However, the last navigational buffer wins.

Nonlocal next-error-functions represent groups of windows that are somehow
related (parts of the same problem, matches for the same input, or so
on). And with them, we can at least expect that the next error still might
be in the current buffer.

This is why I proposed window-local variables to bind a group of windows
to their parent navigational window.

I don't see how that solves anything.

reply via email to

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