On Oct 10, 6:13 pm, Chris Jones <cjns1...@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) -- http://mail.python.org/mailman/listinfo/python-list
