I know that Vim allows a client server mode (:h clientserver): it is possible to turn it into a server which will get some commands and execute them and as a client which will send the commands to the server.

I get how it works, but I can't imagine a practical use of this feature: in which cases is it useful, and what workflow can be created using this feature?

So my question is simple: What is the use of the client server mode of Vim?

(I point out again that my question is not about how to make it work or how it works but why use it.)

  • 3
  • 2
    I'm inclined to close this as too broad.
    – muru
    May 26, 2016 at 10:30
  • 3
    I would understand the closing as too broad. SE maybe isn't the most adapted platform to this question but I feel like I'm missing something about this feature so I thought other could benefit of these answers.
    – statox
    May 26, 2016 at 10:42

6 Answers 6

  • Before the channel/job recent feature of Vim 7.4, the client-server feature was the only way to do a decent background compilation -- without any dependency to Python. We start compilation as a background job, and when it finishes, it notifies back to vim, thanks to the client-server channel, that it has finished.

  • It's also indirectly used by "plugins" like pyclewn to integrate a debugger into vim. Actually pyclewn uses the +netbeans feature (that is built on top of +clientserver). Other notable projects use this netbeans interface to integrate vim with an IDE -- see :h netbeans-intro.

  • It's also used by some tests plugins like vimrunner to run tests in Vim from the command line. I use it to tests my plugins on travis.

  • I also remember synchronizing my clicks in xdvi interface to my LaTeX source code thanks to +clientserver.

  • 2
    So it is useful not to be used by the user directly but by third party application. Thanks for your answer that is pretty interesting.
    – statox
    May 26, 2016 at 12:01
  • 4
    @statox Yes. That's the main use cases I see: simple integration with external tools. Simple because we can feed vim commands and functions through the command line. May 26, 2016 at 13:16
  • 1
    Eclim is another example of this.
    – goldilocks
    May 26, 2016 at 14:27

My use of this is a little more simplistic (and perhaps commonplace) than Luc Hermitte's.

If you start an instance of gvim with this compiled in (and it is, and has been for a long time, on, e.g., major linux distros like Fedora and Debian), it starts in server mode. I emphasized "gvim" because what I'm about to describe does not seem to apply to a singular vim instance in a GUI terminal (although I suppose it could be if you use the paramater appropriately).

Anyway, you can then open any file from anywhere in that gvim instance with gvim --remote [file path] (with no --servername specified). I'm a fan of this because I don't navigate the filesystem much directly with vim; instead I use an orthodox file browser (midnight commander) -- or rather, piles of them open to different locations since mc is lightweight and allows for various color scheme skins to simplify differentiating between them (so I tend to have two or three open in separate tabs in at least one GUI terminal). However, I think the same principle will apply to any file browser which allows you some form of customized hotkey you can associate with gvim --remote %f. In mc I have it in the user menu, so F2 + e and the highlighted/selected file is sent to the gvim instance.

This gets a little better: If you open a second gvim instance, say, on monitor #2 of the same desktop, or a separate desktop, and perhaps a different colorscheme in that one, and this time give it an explicit --servername foo, you can send files to that instance instead with:

 gvim --servername foo --remote [file path]

Something which may or may not come in handy depending on the scope of what you are doing, etc.

  • 1
    That's a use case I hadn't envisaged but indeed if you don't like to navigate through your files from Vim that can be a good workaround.
    – statox
    May 26, 2016 at 11:59
  • Well, I wouldn't consider it a "work around" since the other thing I'm doing, minimally, with the file browser at the same time is glancing at files in the same locations (for text via less, which is instantaneous and one key to exit) and possibly sending them to applications other than vim that also have a remote mode like this (many things do now, including other "editors" which I sometimes use to leave stacked tabs of headers for viewing, and also web browsers). Put another way, I'd say navigating the fs with vim seems like a work around for not using mc and --remote, ;)
    – goldilocks
    May 26, 2016 at 12:10
  • 1
    Yup that's a workflow in itself and not a workaround, my phrasing wasn't ideal but I understood the idea of your answer ;-)
    – statox
    May 26, 2016 at 12:13
  • 1
    When working with Visual Studio, I do most of my editing in Vim. I use this feature to open the current file (with the cursor in the same location) at a keystroke. See the Vim as an external tool section on the Integrate gvim with Visual Studio Vim Tips page for how to set this up.
    – Rich
    Jul 9, 2018 at 15:24
  • 1
    For those interested, I have discussed in unix.stackexchange.com/q/588202 how to apply the same idea for a singular Vim instance in a GUI terminal instead of Gvim.
    – Quasímodo
    Jul 6, 2020 at 14:07

Embedded development. A lot of times in embedded development you have a IP socket, but limited local hard drive space, or no non-volatile memory, or any number of other things. You can start a server on the embedded board, and then client into it on your development computer and have all your configuration and tags setup locally.

  • 5 years later and I would LOVE to know how to do this. In my case, I want to run vim in server mode within a Docker container, and client into that vim server from my Docker host (i.e my laptop). I can't find anything useful about what ports, etc. the server starts up on in :h server Nov 23, 2021 at 15:50

I wrote my masters thesis using Vim, LaTeX and BibTeX. To manage my BibTeX references, I used a program called JabRef. JabRef has a neat little feature where you can connect it to a Vim server instance, and then you can "push" the BibTeX reference from JabRef to the LaTeX document that you are editing in Vim.


My workflow is similar to what goldilocks said in his answer. I use vim8's :terminal feature in combination with --remote option. I maintain 2 window layout in vim. Code in left window and terminal on the right. I use the right window(terminal) to run compilations, navigate file system and open files in current vim instance(from the terminal). This flow allows me to operate with very less mouse involvement.

I use gvim and icewm(any window manager should do)

Start a gvim instance

gvim somefile

Inside gvim, open terminal in vertical split

:botright vertical terminal
(or) short form
:bo vert term 
"botright" splits the window to right

In the terminal window split

gvim --remote-send '<C-w><C-w>' --remote anotherfile

"--remote-send" will send Ctrl-W Ctrl-W to remote gvim instance(in our case, current instance) 
to put the cursor in the left window. Otherwise, the terminal split would be replaced by
'anotherfile' buffer.
"--remote" will open 'anotherfile' in left window.

You can create aliases to these long commands in your .zshrc/.bashrc and shorten them to your liking.

With this workflow, I rarely move out of my gvim instance and rarely use the mouse.


My common use case is to open files in vim from a debugger (Visual Studio, Xcode, etc). I want all the files to open in the same vim window, so I run it as a server and use --remote commands to open the files and jump at the right line and column (with +"call cursor()").

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.