22

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

  • 2
  • 2
    I'm inclined to close this as too broad. – muru May 26 '16 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 '16 at 10:42
20
  • 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.

  • 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 '16 at 12:01
  • 3
    @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. – Luc Hermitte May 26 '16 at 13:16
  • 1
    Eclim is another example of this. – goldilocks May 26 '16 at 14:27
12

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.

  • 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 '16 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 '16 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 '16 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 '18 at 15:24
5

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.

1

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.

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.