What are practical uses of the client-server mode?

Question

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.)

Answer 1

• 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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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()").