tags:

views:

1062

answers:

12

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  A: 

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.

Steve Rowe
+8  A: 

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

Johan
Exactly right. I learned vi in order to participate in newsgroups over two transatlantic hops. I was able to carry on typing in the face of 5 second lag.
slim
+8  A: 

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.

CMS
A: 

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.

ayaz
+5  A: 

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

dreeves
Sometimes the files is to big to be moved like that.
Johan
A: 

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)

rascher
Is that because of extra bytes it sends, or because it taxes the CPU for big files?
John Fouhy
@John Fouhy I'm not sure! When running `script` with both options, the resulting file with black and white has 50 fewer characters. It looks like it is sending another couple of bytes each time the color changes.
rascher
(continued) I think the CPU is a lot more limiting, however. Running `top` while editing a long html file, CPU sometimes spiked to 100% with color (and was choppy), but did not approach that at all for no-syntax. (a purely unscientific study, of course!)
rascher
+5  A: 

Few things to look into.

  • :he lazyredraw
  • :he ttyfast
  • :he nofsync
gregf
+2  A: 

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 letter x
  • 5w -- move 5 words forward
  • ci( -- replace what's between the parentheses
  • dap -- delete current paragraph
  • and a long etcetera.

I miss those commands all the time when typing in browser's textareas, like now :)

Roberto Bonvallet
+1  A: 

Are you on SSH? If so, use SSH compression. ssh -C should help quite a bit.

Michael
+2  A: 

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.

asgeo1
A: 

Slow vim startup by Depesz is probably not your case, but maybe it helps you too.

Grzegorz Gierlik
+1  A: 

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.

Benj