best vi / emacs python features

[Chris Jones]

[..]

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

 

[TerryP]

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)

 

[Jorgen Grahn]

hello,

* this is not a troll *

which kind of help you have with your favorite editor ?

Syntax highlighting and help with the indentation (move to the
right after an else:, keep in the same column normally, etc).
Nothing else specific to Python.

personnally, I find emacs very nice, in the current state of my
knowledge, when I need to reindent the code.
you know how this is critical in python...

Moving a block one step right or left? Oh, I use that, too.

I am also a heavy user of dabbrev-expand (that's an Emacs term, but
it exists in Vim too). Also some other vital features which aren't
specific to Python. The best help an editor can give is language-
independent.

/Jorgen

 

[Hans Georg Schaathun]

When opposing vi to emacs, there's is no possibility you get
: constructive and objective answer, because basically, what can do with
: one, you can also do it with the other.

You seem rather negative. I could not see any request from OP to
oppose vi to emacs. All I could see was a questions about features
people actually use.

And as another user of less than 1% of the features in vim, I found
the few posts actually focusing on that question rather interesting.
Thanks.

:-- George

 

[Lawrence D'Oliveiro]

Being a vi fan, I can just tell you that emacs is for loosers, and no
one will dare to challenge this.

Is it better to be loose or tight?