When I open a vertical split in vim, it takes my current line and bumps it to the top of the buffer (scrolling the entire file up). How do I get vim to retain its current position?
-
What command or key are you using exactly? I'm wondering because both `Ctrl-W-V` key and `:vsplit` doesn't move cursor for me. – xaizek Aug 02 '12 at 17:24
-
Have you altered your _vimrc in any fashion? – EBGreen Aug 02 '12 at 17:55
-
Here's my vimrc: https://gist.github.com/1bf9c5228c74cbb2ed1d I'm using ctl+w, v to open the split, but :vsplit exhibits this behavior as well. – cmhobbs Aug 02 '12 at 21:21
-
I didn't see anything likely in your .vimrc. It's probably one of your plugins. You could try starting vim as `vim -N -u NONE` and see if the problem goes away. Since `:vsplit` causes the problem, too, it's probably an autocommand rather than a mapping. You could try `:au! filetypedetect` (to get rid of that group and make the rest easier to see) followed by `:au` to list all the autocommands and see if any look suspicious. – garyjohn Aug 02 '12 at 22:14
-
It's exhibiting the same behavior while running vim -N -u NONE. The only plugin i have is bufferlist. I went so far as to remove it to no avail. Note that this occurs on both Debian and OSX 10.8. – cmhobbs Aug 03 '12 at 03:21
2 Answers
EDIT: REAL ANSWER: see https://stackoverflow.com/questions/9625028/vim-buffer-position-change-on-window-split-annoyance
TLDR: This behavior only happens on the first time a new window is created. If you close the window and do it again, the cursor in the new buffer is the same as in the old buffer. The answer on there was to do something useless that opens then closes a window, and then to do your vertical split.
Here's another .vimrc mapping that wraps the answer from stackoverflow to do that for you:
map <C-S-O> :tabnew<CR>bwipeout<CR>:vs<CR>
So when you press ctrl-shift-o it will open a new blank tab (:tabnew<CR>), delete the buffer (:bwipeout<CR>) and then do your vertical split (:vs<CR>)
Hope this is better - works perfectly for me. Thanks for making me want to figure out something usable to work around this annoying behavior!
This happens all the time to me! I recently came up with an answer that works most of the time (better than nothing though). Put this in your .vimrc:
map <C-S-O> mmH:vs<CR>`m<C-W>l`m<C-W>h
Everytime you press ctrl+shift+o it should do a vertical split and put the cursor on the same line and column you had it in the original buffer before you split.
The behavior in vim that this tries to get around is when the buffer you are editing is larger than can be currently displayed. Depending on where the cursor is in the buffer (exactly in the middle, upper-half, lower-half), once you do a :vs (vertical split), it will scroll the new buffer down or up to where it thinks best.
The .vimrc mapping above is doing:
map <C-S-O> map ctrl-shift-o to run this
mm mark the current cursor position
H move the cursor to the top of
the buffer
:vs<CR> do a vertical split
`m move to line and column of mark
<C-W>l move focus to the right to the
original buffer
`m move the cursor in the orig buffer
back to the marked position
<C-W>h move back to the new buffer on
the left
Again, it works most of the time for me, not sure why it doesn't work all the time. Anyways, hope this helped some
- 271
- 2
- 4
-
Actually, 'set splitright' from the comments in the accepted post you linked resolved the issue, however the entire thread was very insightful. Accepting because the linked solution resolved my issue. – cmhobbs Aug 07 '12 at 13:27
This might be happening because you have long lines that are getting bunched up by the vertical split. If you :set nowrap and then :vsp you'll notice that it doesn't happen.
- 426
- 4
- 8
-
Setting nowrap doesn't appear to have any affect on it at all. Even if I have a buffer with lines short enough to keep from wrapping with the split, my cursor still jumps to the top of the screen. – cmhobbs Aug 04 '12 at 12:56
-
-
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 5 2012 10:17:30) Included patches: 1-411 – cmhobbs Aug 07 '12 at 13:23