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

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

Yes. This was my appeal to keep the existing integration of xref with
next-error-function. Eli disagreed.

What can we gather from that?

I could gather only that we need to support this case in next-error
before enabling next-error in xref.

So I stated the same as you, Eli disagreed, and we're going to conclude that you are right? Good job.

The primary question is not how many users asked for it many years ago,
but how many users are using it now.

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

Obviously, get-mru-“next-error”-window, i.e. a combination of both.

I have no idea what that means, really. Are we going to store a reference to a window instead of a reference to a buffer? And then take the reference to the buffer from that window?

Seem like lots of complexity for nothing.

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?

Isn't it so that the user will remember which navigation displayed
a given window?

Sorry, _what_ is so?

The users hopefully remember which navigation displayed a given window.

Did your previous sentence make sense? Did you actually mean "Won't users remember..."?

And to answer the question, I don't think so. At least, not every time.

It seems kind of pointless to answer an observation about added complexity with "won't users remember everything?", don't you think?

With your approach, no window will affect other windows. Even if I ran M-x
rgrep, and I see its buffer in the current frame, I'll also have to
remember which window it ended at. And if I never clicked on a link in the
*grep* buffer, I can't use C-x ` in any window, I'm assuming.

C-x ` in any window will use the global value, i.e. the last navigation.

So, not only we'll have local values, we'll also have a global one?

Upon invoking that command, will focus immediately jump to the one window associated with the navigation buffer?

So continuing a navigation in other buffers/windows won't
continue Flychecking of an unrelated buffer.  So Flychecking should not set
the global value of next-error-last-buffer.

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.

AFAIS, this is the point of the current discussion on emacs-devel -
to fix xref's window management to work like *compilation* and visit
navigated windows predictably.

*compilation* isn't afraid to use different windows when it's convenient. It definitely reuses another window if the buffer it's going to jump to is already displayed.

But if we have a new command, I could also allow selecting from some of the
existing buffers which contain "nonlocal" next-error-function's.

Why only “nonlocal”?

Because otherwise there'll be too many options too choose from. To use a different buffer, the user can switch to it first anyway.

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.

reply via email to

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