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

[TerryP]

On Oct 10, 6:13 pm, Chris Jones <cjns1... at gmail.com> wrote:
> Hmm.. On *nix systems, decent applications understand the $EDITOR
> environment variable - don't know about gnome & friends, though.
>

I tend to write programs that understand EDITOR, BROWSER, etc; wish
the rest of the world did.

> 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?

Nothing really, it only does what it was tasked with. Last compiled
source: http://pastebin.ca/1611045 which was built out of a msvc
project in some measure of haste.

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


C:\Documents and Settings\Terry>gvim --servername TEST

C:\Documents and Settings\Terry>gvim --servername TEST --remote-send
":!start no
tepad sucks<CR>"

works as expected.


>
> 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 assume using vim in client mode, only serves to send data to the
server via some pre defined OS-specific method before exit()'ing.


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

Somehow, I doubt vim's clientserver feature is any where near as
powerful as the Id Tech 3 engine mates client and server, but then
again they service different problems ^_^.


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

I believe that clientserver may depend on access to the X display
under unix, or at least it doens't works on the X'less ssh connection
I tested with last week. Under Win32 it probably mucks about with
winmessages or ole stuff. (Note: my primary work station is BSD, not
WinNT)