[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: |
Mon, 1 Feb 2016 01:38:43 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 |
On 02/01/2016 12:57 AM, Juri Linkov wrote:
In the message above, he was replying to my message, where I said: "On the
other hand, while *xref* is visible, `next-error' will keep working for its
results".
Clearly, this describes a successful case as opposed to the problematic one
where *xref* is hidden that evidently needs fixing.
Yes. This was my appeal to keep the existing integration of xref with
next-error-function. Eli disagreed.
What can we gather from that?
On the other hand, if we just use the global next-error-last-buffer value,
we'll just as well "continue the xref-navigation even when *compilation* is
visible in an adjacent window".
And lose the support for the case of simultaneously active navigations
in different windows/frames.
Yup. Did you have many requests, from different users, before
introducing this support?
When the number of next-error-function windows is more than one, then
there's a dilemma which one to use.
Let's use the last one. That would definitely simplify things.
Indeed, using (get-mru-window 'visible t t) makes sense.
I don't follow. The window returned by the above won't necessarily have
next-error-function set. And, again, this ignores the Flycheck case.
If the "previous" navigation buffer is visible, you can also continue
navigation by going to it, and using one of the links there.
If it's not visible, it would make remembering which window belongs to
which navigation, even more difficult.
Isn't it so that the user will remember which navigation displayed
a given window?
Sorry, _what_ is so?
At least, with window-local values the Flycheck navigation in the given buffer
will be confined within the selected window and won't affect other navigations
in other windows.
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.
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?
Does every navigational window get a second, dedicated window for its
locations? Often, we don't have many windows to spare.
Hence my proposal to equate the value nil of next-error-last-buffer with
"use the current buffer".
What/who and how would nullify/reset next-error-last-buffer?
A new command. Or maybe a special value of the prefix argument to
`next-error'? M-0 C-x `, maybe?
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.
- bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason, (continued)
- 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, 2016/01/29
- 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 <=