On Oct 8, 3:29 am, Chris Jones <cjns1...@gmail.com> wrote: > I do have a question: > > You mentioned Vim's clientserver mode. > > What's it good for?
It's most valuable for sending data to an existing instance of vim, by name. Both files and keystrokes can be sent fwiw. vim basically organizes it self into buffers, windows, pages, and servers. A buffer is essentially a file, a window a look into a buffer, a page a group of windows, and a server is an instance of vim (group of pages). As a matter of standard operating procedure, I organize tab pages into module or project oriented workspaces; each page usually contains a split window: open to a source file and a corresponding header^* file. It's a work flow I got used to using for dealing with C++ and Perl code, but it is still useful for Python as well. On top of that, I sometimes group instances of vim into 'servers' by type. So for example, I may have a vim servers (instances) each for FooProject, BarPorject, and another for editing personal documents or configuration files. 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. 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. GNU Screen and a decent terminal emulator can be more handy then clientserver, when the work station supports it that is;). As far as I know, both GNU Emacs and XEmacs have client/server system as well. ^* by header, I mean things like C/C++ header files, Perl/Python modules, etc. -- http://mail.python.org/mailman/listinfo/python-list
