[vim/vim] Introduce 'uselast' option for 'switchbuf'. (#1652)
LemonBoy
This behaviour is more intuitive IMO, full backward compatibility is achieved by introducing a new option, a test is provided but makes no sense, gotta adjust it if you like the patch.
Cheers.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/1652
Commit Summary
- Introduce 'uselast' option for 'switchbuf'.
File Changes
- M runtime/doc/options.txt (2)
- M src/option.h (3)
- M src/quickfix.c (8)
- M src/testdir/test_quickfix.vim (8)
Patch Links:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Yegappan Lakshmanan
On Sun, Apr 23, 2017 at 7:03 AM, LemonBoy <vim-dev...@256bit.org> wrote:
>
> This behavior is more intuitive IMO, full backward compatibility is
> gotta adjust it if you like the patch.
>
the previous window instead of the window just above the quickfix window.
Is that correct? I am assuming that if the file is already opened in another
window, then the cursor will move to that window.
Note that the 'switchbuf' option is used when switching between buffers
using any of the buffer commands or by the quickfix commands. So you need
to add code to other buffer switching commands like ':sbuffer', ':sbnext', etc
to support this new option value.
- Yegappan
vim-dev ML
> achieved by introducing a new option, a test is provided but makes no sense,
> gotta adjust it if you like the patch.
>
the previous window instead of the window just above the quickfix window.
Is that correct? I am assuming that if the file is already opened in another
window, then the cursor will move to that window.
Note that the 'switchbuf' option is used when switching between buffers
using any of the buffer commands or by the quickfix commands. So you need
to add code to other buffer switching commands like ':sbuffer', ':sbnext', etc
to support this new option value.
- Yegappan
>
LemonBoy
If I understand correctly, when jumping to a quickfix entry, you want to use
the previous window instead of the window just above the quickfix window.
Is that correct? I am assuming that if the file is already opened in another
window, then the cursor will move to that window.
Yes.
Note that the 'switchbuf' option is used when switching between buffers using any of the buffer commands or by the quickfix commands. So you need to add code to other buffer switching commands like ':sbuffer', ':sbnext', etc to support this new option value.
Of course, but I don't think it makes sense to do so for the commands handled in do_buffer and buflist_getfile (which are the only ones that respect switchbuf afaik), the documentation states more or less explicitly that it is valid for the qf commands only.
—
You are receiving this because you commented.
Tony Mechelynck
I don't read anything about "only for quickfix" in the docs, quite the contrary:
useopen [...] This setting is [...] also used in all buffer related split commands,
for example ":sbuffer", ":sbnext", or ":sbrewind".
usetab Like "useopen", but [...]
IIUC, only the split, vsplit and newtab values introduce behaviour specific to quickfix windows. Indeed I :set switchbuf=useopen in my vimrc, which allows me to go to any open window (of the current tabpage) by name using :sbuffer rather than by ordinal number using Ctrl-W w with a count
—
You are receiving this because you commented.
LemonBoy
I don't read anything about "only for quickfix" in the docs
I am talking about the new uselast option which I've documented more or less clearly that is only respected by the quickfix commands only.
—
You are receiving this because you commented.
Ben Fritz
> Hi,
>
> On Sun, Apr 23, 2017 at 7:03 AM, LemonBoy <vim-dev...@256bit.org> wrote:
> >
> > This behavior is more intuitive IMO, full backward compatibility is
> > achieved by introducing a new option, a test is provided but makes no sense,
> > gotta adjust it if you like the patch.
> >
>
> If I understand correctly, when jumping to a quickfix entry, you want to use
> the previous window instead of the window just above the quickfix window.
> Is that correct?
Isn't that what already happens without this option?
I have a quickfix list open right now. When I open a new window then do CTRL-W_b to go to the quickfix window, pressing enter on any item jumps to the result in the previous (top) window, not one of the two windows directly above the quickfix window.
vim-dev ML
> Hi,
>
> On Sun, Apr 23, 2017 at 7:03 AM, LemonBoy <vim-dev...@256bit.org> wrote:
> >
> > achieved by introducing a new option, a test is provided but makes no sense,
> > gotta adjust it if you like the patch.
> >
>
> the previous window instead of the window just above the quickfix window.
> Is that correct?
Isn't that what already happens without this option?
I have a quickfix list open right now. When I open a new window then do CTRL-W_b to go to the quickfix window, pressing enter on any item jumps to the result in the previous (top) window, not one of the two windows directly above the quickfix window.
LemonBoy
Isn't that what already happens without this option?
No, if you're lucky enough you can get a layout where the problem doesn't show.
—
You are receiving this because you commented.
Codecov
Codecov Report
Merging #1652 into master will increase coverage by
<.01%.
The diff coverage is100%.
@@ Coverage Diff @@ ## master #1652 +/- ## ========================================== + Coverage 74.87% 74.88% +<.01% ========================================== Files 76 76 Lines 124888 124890 +2 ========================================== + Hits 93516 93521 +5 + Misses 31372 31369 -3
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/quickfix.c | 91.39% <100%> (ø) |
⬆️ |
| src/channel.c | 83.64% <0%> (-0.14%) |
⬇️ |
| src/gui_gtk_x11.c | 47.28% <0%> (-0.11%) |
⬇️ |
| src/term.c | 53.37% <0%> (-0.06%) |
⬇️ |
| src/gui.c | 45.5% <0%> (-0.06%) |
⬇️ |
| src/window.c | 81.08% <0%> (-0.04%) |
⬇️ |
| src/message.c | 68.52% <0%> (+0.45%) |
⬆️ |
| src/version.c | 80.3% <0%> (+1.01%) |
⬆️ |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update b7637c4...1e61374. Read the comment docs.
—
You are receiving this because you commented.
Bram Moolenaar
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.