I'm using vim over a slow connection and it is a little painful. Is there anything I can do in vim to alleviate the pain?
Vim was designed for slow connections. Are you taking advantage of the motion commands and line selection operations? My suggestion is to learn the non-cursor key parts of Vim really well.
vi was created to use over 300 baud modem, that is what there is all those funny and strange (and short) command to move and navigate. Learn them...
Play with things like
:10 -> jump to line 10 7j -> move 7lines down
And since my keyboard has a little physical dot at the keys f and j, I use the dot on key j to easy find the vim navigation "hjkl".
But the best thing is to never ever scroll at all, search to move is a life saver. When you search your pointer ends up right at the thing you search for, meaning that those slow navigations is not needed. This is really useful if you end up editing really big files over ssh...
/Johan
You can try setting off timeout and ttimeout, this way Vim will wait until either the complete mapping or key sequence has been received.
Or you can increase the timeoutlen value, this is the time in milliseconds waited for a key code or mapped key sequence to complete.
One can dull the pain a wee by using shortcuts to move up and down the file and along the lines, but as I have experienced often, doing anything on a slow connection is very painful. I find that when it is possible I can save a lot of time and frustration by scp
'ing the file over to my workstation, editing it there peacefully, and loading it back.
I think the best thing to do is edit it locally and transfer the file. This can be automated so that it feels like editing remotely:
http://vim.wikia.com/wiki/Editing_remote_files_via_scp_in_vim
See also the answers to this related question:
http://stackoverflow.com/questions/601532/remotely-programming
My recommendation is to turn off syntax highlighting in vim. Particularly for large files, this makes vim respond much faster for me. (:syntax off
)
Edit: This might also help, from the vim documentation:
http://www.vim.org/htmldoc/term.html#slow-fast-terminal (it looks like the suggestions posted already have some of the things from this doc)
Over a slow connection, it's painful to move the cursor character by character, because you don't get immediate visual feedback, so you always end up moving too much or too little.
So what's most effective to me is to use smarter movements and commands, like:
fx
-- jump to next letterx
5w
-- move 5 words forwardci(
-- replace what's between the parenthesesdap
-- delete current paragraph- and a long etcetera.
I miss those commands all the time when typing in browser's textareas, like now :)
Are you on SSH? If so, use SSH compression. ssh -C
should help quite a bit.
The trick to working out what is causing the performance issues is to disable everything in vim, and then slowly introduce parts back in until you work out what is causing your performance issues.
I.e. delete (or move or rename) the following files/directories to quickly disable:
C:\Program Files\Vim\_vimrc
C:\Program Files\Vim\vimfiles
C:\Program Files\Vim\vim72\autoload
C:\Program Files\Vim\vim72\plugin
On Unix/Linux/OS X, these files should exist at:
~/.vim/plugin
~/.vim/autoload
If you can't find it in either of those places, then the :version
command can show you which .vimrc
files are being used. The plugin directory should be close by.
Start up vim - it will probably look weird without any settings. But it should perform acceptably now.
Then start introducing bits back in piece-by-piece until you find out what is causing the problem.
I did this and found the following stock plugins cause problems when using Vim over a VPN:
- matchparen.vim
- netrwPlugin.vim
- vimballPlugin.vim
Most of the problems these plugins introduce is adding new autocmds (like during BufEnter), which do not perform well when editing remote files. You may find you also have your own plugins which will may be causing performance problems.
I then wrote a function to delete these autocmds for when working remotely:
let g:NotEditingRemotely = 1
function! s:ToggleRemoteFile()
if exists("g:NotEditingRemotely")
" Disable the matchparen.vim plugin"
:NoMatchParen
" Turn off detection of the type of file"
filetype off
" Disable the netrwPlugin.vim"
au! Network
au! FileExplorer
" Remove tag scanning (t) and included file scanning (i)"
set complete=.,w,b,u,k
" Remove these autocommands which were added by vimBallPlugin.vim"
au! BufEnter *.vba
au! BufEnter *.vba.gz
au! BufEnter *.vba.bz2
au! BufEnter *.vba.zip
unlet g:NotEditingRemotely
:echo 'Remote Edit mode turned on'
else
" Enable the matchparen.vim plugin"
:DoMatchParen
" Turn on detection of files"
filetype on
" Add back in tag scanning (t) and included file scanning (i)"
set complete=.,w,b,u,t,i,k
let g:NotEditingRemotely = 1
:echo 'Remote Edit mode turned off'
endif
endfunction
command! -nargs=0 ToggleRemoteFile call s:ToggleRemoteFile()
noremap <F6> :ToggleRemoteFile<CR>
Put in your vimrc and see if it makes a difference.
Slow vim startup by Depesz is probably not your case, but maybe it helps you too.
I'm not sure if this is applicable but if you're connection is at all temperamental and likely to drop out I'd use vim with "screen". screen gives you a virtual terminal which you can just reconnect to if it drops out so you're vim window is persistent.