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?
问题:
回答1:
vi was created to use over 300 baud modem, that is why 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...
回答2:
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.
回答3:
Few things to look into.
- :he lazyredraw
- :he ttyfast
- :he nofsync
回答4:
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:
Remotely Programming
回答5:
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 :)
回答6:
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.
回答7:
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.
回答8:
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)
回答9:
Are you on SSH? If so, use SSH compression. ssh -C
should help quite a bit.
回答10:
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.
回答11:
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.
回答12:
Slow vim startup by Depesz is probably not your case, but maybe it helps you too.
回答13:
For repeated tasks, you can map a series of commands to a single keystroke. Lets say you want to find and replace a word (foo with bar), but not all instances of it
/foo
:map g cwbar^v^[n
Type g if you want to replace and n to skip
- cw= change word
- ^v = crtl+v to enable recording keystrokes like ESC and ENTER
- ^[ = ctrl+ESC
- n = next instance of search string
回答14:
do not set the option cursorline
or colorcolumn
. Otherwise vim will lag considerably.
回答15:
Use mosh: http://www.linuxscrew.com/2012/04/11/why-mosh-is-better-than-ssh/?replytocom=804158#respond
apt-get install mosh
yum install mosh
(or whatever appropriate command for your system)
And then just use "mosh" instead of "ssh".
It was designed for slow connections, and from a quick test over my slow 3G connection, to a server, it seems to support it quite well.
NB When connecting to a non-standard port, be sure to update /etc/ssh/ssh_config