On Thu, Oct 08, 2009 at 12:59:00AM EDT, TerryP wrote: > On Oct 8, 3:29 am, Chris Jones <cjns1...@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 -- http://mail.python.org/mailman/listinfo/python-list