This is really starting to get on my nerves, which is weird because it\'s such a small issue.
Let\'s say I start (g)vim 7.3 (windows OR linux) with no plugins/no vim
I can reproduce the behaviour, which with your description would (at first sight) appear to be a bug, indeed. But I noticed the following things:
:vert split has the same behaviour as ^Wv
:debug ver split (... cont) confirmed there wasn't an obvious script/autocommand interfering
It only happens on the first time split. In other words, this is a workaround: ^Wv^Wc^Wv
the cursor does in fact not move in the original window. The 'new window' appears on the left (which you name the original window). This cannot be shown with :echo winnr() or similar, but you can make it more apparent by doing e.g. :vert new instead of :vert split: the new, empty window appears on the left side.
Instead of this, you might trick the split to have 'second split' behaviour by doing something 'useless' before
:tabnew|bwipeout
Now, ^Wv has the desired behaviour first time around.
The splitright, splitbelow options
can be used to control (to an extent) where newly created (split) windows appear
The winrestview() function
Can be used to explicitely restore the exact view of a window. Use it like so:
:let savex=winsaveview()
savexnow contains something like{'lnum': 1, 'leftcol': 0, 'col': 0, 'topfill': 0, 'topline': 1, 'coladd': 0, 'skipcol': 0, 'curswant': 0}describing the state of the current view.(do stuff, like ^Wv)
:call winrestview(savex)This is obviously a lot more flexible but you might not need it.
I tested it on a Windows machine with gvim and could reproduce your problem, here is a workaround that worked for me adding next commands to vimrc (I got it with :e $MYVIMRC):
set splitright
function MySplit()
vsplit
execute "normal \<C-w>\<C-w>"
endfunction
nmap <C-w>v :call MySplit()<CR>