Currently I'm doing it by SSHing into a server, and executing Vim on the server. This has the benefit of not having to deal with cumbersome syntax of opening files from a remote server over SCP, and, more importantly, being able to really quickly navigate the server's filesystem. On the other hand, it has lag, which make editing kind of hard.

scp is a secure copy protocol. It authenticates the same way as ssh, so your ssh key needs to be available, etc. There are various other protocols supported (see :help netrw-externapp) but scp is probably the easiest if you are already using ssh to the same place.

You can browse directories this way, just make sure the path ends with a /. Otherwise vim turns it into a new file.

:w automatically writes the file via scp. If the write fails for some reason, you should notice, since they'll be a "shell returned 1" kind of thing in the status bar. However, beware: if you don't notice, vim doesn't know and that can have consequences -- for example, if you now quit, it won't warn you. It's particularly easy to miss this if you use :wa a lot ;| That's the only caveat I have.

+1 I was just about to write this. The netrw plugin (which is usually installed by default) has a wide variety of ways to read remote files.
–
Greg HewgillOct 23 '13 at 20:36

I was referring to this option when I said: "This has the benefit of not having to deal with cumbersome syntax of opening files from a remote server over SCP, and, more importantly, being able to really quickly navigate the server's filesystem" This way seems very limited to me.
–
jcoOct 23 '13 at 22:34

1

To be fair, your question originally did not mention "remote server over SCP", that was edited in later.
–
Greg HewgillOct 24 '13 at 0:15

@GregHewgill : Thanks for that note as I'm a bit baffled -- this is the most simple and straightforward method for general purposes (no offence to SSHFS!). If appending an URL to a filepath is relatively cumbersome, I'm curious as to how the task being performed actually requires someone sit down with an editor to do it...esp. since you can just up arrow the command. But to each their own.
–
goldilocksOct 24 '13 at 0:46

@GregHewgill yeah, I know, I wrote the question on my phone while moving so I left some stuff out unintentionally. goldilocks, I open and close files all the time. Navigate the filesystem too and open from there. Appending a URL+path was more cumbersome than just "being there".
–
jcoOct 24 '13 at 8:03

then edit the files locally at your own leisure. Zero lag. You get to inspect all the files before you commit them:

rsync -e ssh -va . remoteuser@remotehost:remotedir

I'm assuming you first create your local dir and cd into that.
You can also make it handle the removal of files, but be really careful with that, because executing that in the wrong directory could nuke an entire directory tree.

rsync -e ssh -va --delete . remoteuser@remotehost:remotedir

What I do is I run it in "dry mode" first, using the 'n' flag, like so:

rsync -e ssh -van --delete . remoteuser@remotehost:remotedir

It will report what it would have done, if it were for real.
If I'm happy with the reported list, I run it again, and remove the 'n' flag.

rsync is very efficient. There are various other flags as well. It's quite sophisticated.

May be you named the most appropriate way - SSH way, but still depending on the very nature of the files edited, you could allocate a little partition, making it shared and put the files there, of course if the security policy allows this action. For this suggestion you might use NFS or Samba most easily, but still editing test file is a general conception in UNIX and may be you have to keep it the way you do it currently.