best vi / emacs python features
OdarR
* this is not a troll *
which kind of help you have with your favorite editor ?
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...:-)
I don't use other python-mode features for the moment, maybe you have
some advices.
I used with success an Xemacs on Solaris, as well as a Aquamacs on
Mac.
For the vi/vim guys, explain us the best features this editor give you
in your py files !
thanks,
Olivier
Jean-Michel Pichavant
constructive and objective answer, because basically, what can do with
one, you can also do it with the other.
Being a vi fan, I can just tell you that emacs is for loosers, and no
one will dare to challenge this.
vi/emacs is like choosing between the Celtics or the Lakers, there is no
reason for that, the fun part resides in being totally devoted to your
choice :o)
For my part I never switched to emacs cause I was tired of getting
syntax error with ':w' inserted everywhere in my code. Bad habits are
sticky.
One feature I have that emacs don't is that I'm able to efficiently edit
a file on a remote machine with vim on a terminal (without graphical
interface), and I'm using it. Apart from that, both solutions are
efficient. I would add that inside a company, it is a good idea to use
the same editor as you can share knowledge, macro, plugins and so on.
JM
Falcolas
wrote:
> OdarR wrote:
> > hello,
>
> > * this is not a troll *
>
> > which kind of help you have with your favorite editor ?
>
> > 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...:-)
>
> > I don't use other python-mode features for the moment, maybe you have
> > some advices.
> > I used with success an Xemacs on Solaris, as well as a Aquamacs on
> > Mac.
>
> > For the vi/vim guys, explain us the best features this editor give you
> > in your py files !
>
> > thanks,
>
> > Olivier
>
> one will dare to challenge this.
I concur 100% with this statement.
That said, I like how my install of VIM 'just works' with Python
files, doing a good job of coloring and auto indentation. I don't
like, however, how an arbitrary colon will trigger auto indentation on
the next line. I'm guessing, though, that this is just an issue with
my particular syntax file.
Garrick
OdarR
> Being a vi fan, I can just tell you that emacs is for loosers, and no
> one will dare to challenge this.
vi is very good for newbees, I recommend it.
> vi/emacs is like choosing between the Celtics or the Lakers, there is no
> reason for that, the fun part resides in being totally devoted to your
> choice :o)
> For my part I never switched to emacs cause I was tired of getting
> syntax error with ':w' inserted everywhere in my code. Bad habits are
> sticky.
just use the other symetric part of your brain.
> One feature I have that emacs don't is that I'm able to efficiently edit
> a file on a remote machine with vim on a terminal (without graphical
> interface), and I'm using it. Apart from that, both solutions are
emacs has the same efficiency on a terminal.
or maybe I don't understand your sentence.
> efficient. I would add that inside a company, it is a good idea to use
> the same editor as you can share knowledge, macro, plugins and so on.
I never used macro with vi or emacs.
I shared know-how for vi or emacs.
I worked in companies full of talented people, open to new
technologies, no issues mixing both editors.
and don't speak of UltraEdit yet :)
Apart of trolling which is also an activity I like,
what are the features vim proposes to Python ?
Olivier
Tim Chase
>> a file on a remote machine with vim on a terminal (without graphical
>> interface), and I'm using it. Apart from that, both solutions are
>
> emacs has the same efficiency on a terminal.
> or maybe I don't understand your sentence.
Perhaps this is a reference to the alt/meta/control/buckey/super
key-chords that emacs is infamous for using that don't always get
reliably transmitted by all terminal-emulation programs and
consoles. It was one of my nudging factors towards vi (and later
vim), because I occasionally used some terminal software in which
alt or shift+control+alt (and other such combinations) weren't
detected. Never had that problem with vi/vim. And when all else
fails, I can usually fall back to ed in a pinch ;-)
-tkc
Jean-Michel Pichavant
>
> Apart of trolling which is also an activity I like,
> what are the features vim proposes to Python ?
>
> Olivier
>
Many, but none that you won't find with emacs, so when I'm stating it is
just a matter of personal preference, I mean it :o) "Vi or Emacs" is the
same question as "straight or gay" (order matters! :D).
No one will come and convince you to use one or the other. Launch both
of them, look at the nice and smooth visual of gvim, compare it with the
ugly skin of emacs and pick your choice !
Beside from trolling, here are the feature I'm using for python:
- syntax highligthts (there are hundreds of different themes, now way
you can't find few you like)
- auto completion of symbols
- code browsing supporting tag files
- (almost) smart indentation
That's it
JM
OdarR
> Perhaps this is a reference to the alt/meta/control/buckey/super
> key-chords that emacs is infamous for using that don't always get
> reliably transmitted by all terminal-emulation programs and
> consoles. It was one of my nudging factors towards vi (and later
> vim), because I occasionally used some terminal software in which
> alt or shift+control+alt (and other such combinations) weren't
> detected. Never had that problem with vi/vim. And when all else
> fails, I can usually fall back to ed in a pinch ;-)
>
> -tkc
yes, this is true that emacs needs ctrl and meta key.
two keys for lots of combinations :-)
Like with vi when I began, I need a cheat list of keystrokes for
emacs.
ctrl is ok. Meta can always be used with ESC.
if you really need to stay on a unknown terminal for some weeks, it is
not complicated to copy/paste your favorite .emacs file (less than 10
lines is for me sufficient). It's just a matter of organization.
Olivier
TerryP
I typically use several editors: /bin/ed, nvi, EDIT.COM, and Vi
Improved.
These are the advantages that I find these various editors give me:
ed -- I can quickly edit files without having to wait on an ncurses
app to start up. Although I rarely have access to GNU versions of ed,
they use readline which is a big perk when you make a typo.
nvi -- smaller and faster then vim, works great over slow ssh links or
when editing huge files. I like nvi over the original vi, because most
of the limitations of the old-school vi are removed; unlimited undo is
the best feature added.
EDIT.COM -- much faster then notepad over remote connections, and it
understands both DOS and UNIX end of lines; meaning I can skip
converting formats, the only downside is it's still a 16-bit program.
vim -- My favourite and most used editor. I like it because it can be
made fairly compatible with vi, but has superior tag stack handling,
and the multiple-window, :ex command line history, and completion
features leave their nvi equivalents in the dust. (vi had no
completion or command history, and lacked split windows.) Vim also has
improved register handling, regular expression support, tab pages for
organizing workspaces, a client/server mode, and most importantly can
be made to adapt itself (e.g. spaces, tabs, eol's) based on file type
without much bother. That makes it much easier to use with Python
files then most editors in my tool bag.
I am a freak: I do not use nor want syntax highlighting. I don't want
my editor to understand mail, irc, or the www either, I want it to
edit text efficiently so I can go on with the rest of my life as soon
as possible. Given the choice of using a space cadets editor like
emacs or something primitive one like ed, I would choose *ed* just to
speed things up and save on wrist strain. Before I read a tutorial
about vi, I used XEmacs very happily---vi just lines up better with
how my brain works.
--
It is also general consensus that I am nuts ;)
TerryP.
Carl Banks
> >> One feature I have that emacs don't is that I'm able to efficiently edit
> >> a file on a remote machine with vim on a terminal (without graphical
> >> interface), and I'm using it. Apart from that, both solutions are
>
> > emacs has the same efficiency on a terminal.
> > or maybe I don't understand your sentence.
>
> Perhaps this is a reference to the alt/meta/control/buckey/super
> key-chords that emacs is infamous for using
It's Esc-Meta-Alt-Ctrl-Shift
Carl Banks
Tim Chase
Sure that's not Winkey+Tab+Fn? :-)
-tkc
:wq!
Chris Jones
[..]
> I am a freak: I do not use nor want syntax highlighting. I don't want
> my editor to understand mail, irc, or the www either, I want it to
> edit text efficiently so I can go on with the rest of my life as soon
> as possible. Given the choice of using a space cadets editor like
> emacs or something primitive one like ed, I would choose *ed* just to
> speed things up and save on wrist strain. Before I read a tutorial
> about vi, I used XEmacs very happily---vi just lines up better with
> how my brain works.
>
> --
>
> It is also general consensus that I am nuts ;)
I don't think so.
Always felt that syntax highlighting for instance is way overrated. Haven't
tried "ed" yet, but since I have already stripped down my everything to what
I thought was minimal, now that you mention it, this may be where I'm bound.
I do have a question:
You mentioned Vim's clientserver mode.
What's it good for?
Thanks,
CJ
Nobody
>> >> One feature I have that emacs don't is that I'm able to efficiently
>> >> edit a file on a remote machine with vim on a terminal (without
>> >> graphical interface), and I'm using it. Apart from that, both
>> >> solutions are
>>
>> > emacs has the same efficiency on a terminal. or maybe I don't
>> > understand your sentence.
>>
>> Perhaps this is a reference to the alt/meta/control/buckey/super
>> key-chords that emacs is infamous for using
>
> It's Esc-Meta-Alt-Ctrl-Shift
Emacs doesn't use Alt, Super or Hyper for any pre-defined bindings,
although you can use them for your own bindings. It does use Meta for
pre-defined bindings, and understands Esc,<key> as equivalent to Meta-<key>.
The most common terminal-related problems are:
1. Your terminal is configured to treat Meta as Alt (i.e. Meta-<key> sends
<keycode>+128 rather than Esc,<key>.
2. $TERM doesn't accurately reflect your terminal; e.g. $TERM is set to
vt100 when the terminal has cursor keys, ANSI colour, or the terminfo
entry for $TERM says that Delete sends ESC,[,3,~ when it actually sends
DEL (similarly for C-h/DEL for Backspace).
3. Not being able to distinguish between BS, CR, LF from C-h, C-m, C-j,
etc. Most bindings which use these keys work with all interpretations
(e.g. C-x C-m <key> and C-x return <key> are bound to the same functions
for all values of <key>). The main exception is that C-h maps to BS on a
terminal, so you need to use M-? (or Esc,?) or F1 for the help commands.
TerryP
> 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.
Carl Banks
> Always felt that syntax highlighting for instance is way
> overrated.
I have all syntax colors turned off except for strings and comments.
I highly recommend this low-key syntax coloring for those who don't
care for the normal psychodelic syntax coloring.
Bright red comments definitely helps them stand out (the easier to
ignore them with), and cool blue strings provide a subtle syntax clue
while not being too distracting. Rest of the text is black.
Carl Banks
Paul Rudin
I quite like a bit of syntax highlighting - it helps to quickly grasp
the structure of code. Of course how much is a matter of taste.
I also like to highlight things that can creep in accidentally and
shouldn't be there - e.g. whitespace at the end of lines, tabs where
there should be spaces.
Jean-Michel Pichavant
> On Wed, Oct 07, 2009 at 07:06:08PM EDT, TerryP wrote:
>
> [..]
>
>
>> my editor to understand mail, irc, or the www either, I want it to
>> edit text efficiently so I can go on with the rest of my life as soon
>> as possible. Given the choice of using a space cadets editor like
>> emacs or something primitive one like ed, I would choose *ed* just to
>> speed things up and save on wrist strain. Before I read a tutorial
>> about vi, I used XEmacs very happily---vi just lines up better with
>> how my brain works.
>>
>> --
>>
>> It is also general consensus that I am nuts ;)
>>
>
>
> Always felt that syntax highlighting for instance is way overrated. Haven't
> tried "ed" yet, but since I have already stripped down my everything to what
> I thought was minimal, now that you mention it, this may be where I'm bound.
>
>
> You mentioned Vim's clientserver mode.
>
> What's it good for?
>
>
> CJ
>
Strange how things can differ from one person to another. Syntax
highlighting is the feature I'm missing the most when I'm using pure vi.
Looks like some are getting annoyed by it, I think it provides useful
and meaningful informations through colors.
JM
edexter
I like alot of the features of both on gvim they show white space
symbols but I find both emacs and gvim a pain to extend
and I need to find a key word and then hilight columns so because of
the complexity it has become rich edit vs scintilla..
I wrote my own syntax highlighter for rich edit 2 for csound but not
with all the complexity I am planning later.. jedit looked
very intresting but I haven't figured out the output window yet they
do have python embeded well jython anyway (like gvim does)
Falcolas
wrote:
I have found that syntax hilighting is useful, as long as it isn't
overwhelming. Zenburn is a great highlighting scheme which is fairly
easy on the eyes to use (no startling colors anywhere), yet the
differences are enough for me to quickly pick out syntax elements.
Garrick
Ross Ridge
>ed -- I can quickly edit files without having to wait on an ncurses
>app to start up. Although I rarely have access to GNU versions of ed,
>they use readline which is a big perk when you make a typo.
I used to fallback on ed when network connections got really slow and
I could log in using Telnet line-mode, but it's been a long time since
the I could tell the difference between the start up time of any editor.
They all, ed, nvi or GNU emacs, start up instantaneously for me.
>nvi -- smaller and faster then vim, works great over slow ssh links or
>when editing huge files. I like nvi over the original vi, because most
>of the limitations of the old-school vi are removed; unlimited undo is
>the best feature added.
I like nvi because by default it's quirk for quirk compatible with the
original vi, including single-level undo. (Well at least until they
screwed things up with the new file/input encoding scheme.)
>EDIT.COM -- much faster then notepad over remote connections, and it
>understands both DOS and UNIX end of lines; meaning I can skip
>converting formats, the only downside is it's still a 16-bit program.
I use MS-DOS Editor from time to time, but mainly because it means I
don't have to change window focus.
>I am a freak: I do not use nor want syntax highlighting. I don't want
>my editor to understand mail, irc, or the www either, I want it to
>edit text efficiently so I can go on with the rest of my life as soon
>as possible. Given the choice of using a space cadets editor like
>emacs or something primitive one like ed, I would choose *ed* just to
>speed things up and save on wrist strain.
But in actual practice you use a space cadets editor like Vim.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
TerryP
>
> Ross Ridge
Actually by space cadets editor, I meant needing one of these:
http://en.wikipedia.org/wiki/Space_cadet_keyboard
--
TerryP.
Chris Jones
> 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
TerryP
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)
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
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Gabor Urban
this is supposed to be a Python mailing list...
Both editors are great and are with great potentials. I do use both of
them daily, though for different purposes. It is meaningless to start
this old issue of preferences anew.
--
Linux: Choice of a GNU Generation
Hans Georg Schaathun
<jeanm...@sequans.com> wrote:
: When opposing vi to emacs, there's is no possibility you get
: 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
Pichavant wrote:
> 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?