Probably gvim is trying to write its swapfile (the disk file where it
saves your changes in order to be able to restart with as little loss as
possible in case of a crash) to the same drive as the file being edited,
which is OK for local files, but can raise performance issues for remote
files.
Solution I (recommended)
----------
Copy the remote file to a local directory, edit it there, and copy it
back when you're done for the day. This is the easiest to figure out how
to do correctly. Also, intermediate saves (if you use ":w") will proceed
OK even if your line to the remote host goes down. All this rigmarole is
unnecessary for readonly files (e.g. when using ":view" or ":sview")
since there are no changes then, hence no swapfile, unless of course you
change your mind and decide to make changes to the file after all.
Solution II
-----------
First,
:set nobackup writebackup
Then, if it still isn't good enough, try to figure out from the help how
Vim figures out where to write its backup and swap files, and make sure
that at least the swapfile is either local or nonexistent.
Best regards,
Tony.
--
In case of atomic attack, the federal ruling against prayer in schools
will be temporarily canceled.
The first thing that occurs to me is the swapfile settings. If
it's trying to write the swapfile to the same remote network
location, you'll get horrid lag. Try
:set directory-=.
or
:let &directory=$TEMP
to instruct vim to write the swapfile(s) elsewhere.
Alternatively, you can shut the swapfile off completely:
:set noswapfile
or reduce the frequency with which it writes to the swapfile:
:set updatecount=10000
One last alternative occurs to me: check the output of
:map
to see if you have any mappings for h/j/k/l and check
:autocmd CursorHold
:autocmd CursorHoldI
:autocmd CursorMoved
:autocmd CursorMovedI
to see if any event is firing that might drag you down.
-tim