[OT] vim clientserver [was: best vi / emacs python features]

[Chris Jones]

On Thu, Oct 08, 2009 at 12:59:00AM EDT, TerryP wrote:
> On Oct 8, 3:29 am, Chris Jones <cjns1... at gmail.com> wrote:

[..]

> It's most valuable for sending data to an existing instance of vim, by
> name. Both files and keystrokes can be sent fwiw.

[..]

> On top of that, I sometimes group instances of vim into 'servers' by
> type. 

Ah, good point, differently configured vim's depending on the task
category.

> When I have programs that launch vim to handle editing tasks, I'll
> often make them send the file to an appropriate vim server, so
> everything is grouped accordingly. Example: when projects require the
> use of Visual C++, I have the IDE set to open most files with a custom
> program: which execs gvim --servername MSVC -- remote-tab-silent
> TheFileNameToOpen.ext. 

Hmm.. On *nix systems, decent applications understand the $EDITOR
environment variable - don't know about gnome & friends, though.

So what does the intervening custom layer do before directing the remote
vim to edit the file? 

Or is it something that comes in handy when the client does not
undertand environment variables?

I noticed that 'clientserver' vim provides a few functions, presumably
to make the process more flexible. But these functions are vim-specific,
naturally, so wouldn't this suggest a client vim + server vim setup?

IOW, apart from adding logic to the process of selecting the server, I
don't really see much else the vim client would be able to do once it
has directed his request to the server.

OTOH, some of these functions, such as server2client(), and the matching
remote_peek() & remote_read() look promising but unless I missed
something, I didn't see anything about an API that would let me call
them outside the context of vim.

Maybe part of what makes the whole thing so confusing, to me at least,
is that I can't fall back on anything I've seen before, where both the
client (vim instance or other application) and the server interact with
the user.

I can think of one particular scenario where the added complexity and
overhead would be more than counterbalanced when using a client server
setup, making for instance a system administrator's chores a lot easier
when he has to work with the same configuration file(s) on a number of
systems, giving him the ability to edit them in a single 'central'
instance of vim, with the benefit of easy diff'ing, cut'n'pasting,
running custom scripts, etc. 

With ssh & remote X that's probably not too hard to set up in a way
that's sufficiently user-friendly.

> So that every file opened through VC will be in one GVim window. The
> same could be done with several webbrowsers, mail clients, and
> newsreaders. It makes using using vim as an external program to
> something fatter much more convenient. 

Even though I only tried with the client application and the vim server
running on the same machine, I've had mixed results in this respect:

Everything appeared to consistently work without a glitch as long as I
made sure that I had the client wait for the vim server to unload the
buffer(s), but there were some pretty strange results as soon as I
dropped the 'wait' bit from my requests: more often than not, I only
managed to create an empty buffer on the server side, and on a couple of
occasions, I even ended up with a buffer that looked just about right in
terms of length, but where all the data had been converted to NULLs
(0x00). 

:-)

Thanks,

CJ