Best Python editor (under Linux)

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Steve" == Steve Lamb <grey at despair.dmiyu.org> writes:
Steve> Ah yes, Emacs.  Emacs is the proof that even the most die hard
Steve> unix fan can succumb to creeping featurism.  Why?  Well think
Steve> about it, "the unix way" is to have a collection of small tools
Steve> which are interchangable, communicate with each other well and
Steve> each do their specific task quite well.

It's all about convenience. The way that Unix utilities communicate
with each other is as text through pipes, and for many things it works
excellently well... but not interactively, and text editing is
interactive. Granted, many things can be run as bulk jobs, such as
when, say, updating from or committing to a CVS repository. In these
cases Emacs uses external utilities.

Steve> "The windows way" is to lump every unrelated task into every
Steve> program in an attempt to out check-box the competition on a
Steve> comparisoon pamphlet.  Now, I ask you, which describes Emacs?
Steve> Clearly the latter.

Emacs is just an editor, albeit a very powerful one. All very powerful
editors need to be fully scriptable, so it also contains an
interpreter for a programming language (and I'm not arguing that ELisp
is the greatest language in history). The rest is simply stuff that
you can take or leave, but which enough people have found useful for
it to be in the standard full distribution.

Steve> I never quite understood what a mail and news reader had to do
Steve> with editing files yet every time the "best mail|news reader
Steve> for unix" comes up gnus is top of the list.

When it comes to such tasks as writing this post, which is basically
an editing task like any other that I prefer to do in my favourite
editor, you're stuck between bringing the news client to Emacs or
bringing Emacs to the news client. Bringing Emacs to the news client
is doable, but only practical in so far as you use Emacs-client, where
you start one 'master' instance and let the rest connect to this as a
server of sorts. That way you get the editing features of Emacs, but
no scriptability outside of the basic editing of posts. Believe it or
not, but bringing the news client to Emacs is not that big a
deal. External utilities are used where possible (SSL, GnuPG,
whatever), and you'll be hard pressed to write a news client in fewer
lines of code in any language than it's done with Gnus, and Gnus is by
far the most featureful one that I've ever seen. If you think that
it's bloat and you don't want it, simply don't load it.

To keep this on topic, I've tried hacking Python in other editors,
including Vim, but it's just not the same. Many of the same basic
editing features are there, and even indentation can be made to be
almost as good in Vim as in Emacs. But Python being a language with an
interactive interpreter, isn't it both wonderful, not to mention very
obvious, that I am able to take advantage of the benefits of it being
interactive? I can change a function and re-evaluate it with a single
chord, I needn't run a separate Python interpreter instance in a
terminal, constantly re-evaluating files, I get the text output from
my application directly in an editor buffer (where it's immediately
useful) instead of a terminal window or a file and so on. Everything
just flows; there's no need to break one's state of mind to change to
something completely different.

Steve> Noone has yet to explain to me why I would want to install a
Steve> 20+Mb editor just for a newsreader.

If you don't like the editor, don't.

Steve>  As a result I stick to slrn which calls my preferred editor
Steve> (was joe, then jed, now vim).  Seems the sensible way to do
Steve> things.  The reader calls the editor, not the editor contains
Steve> the reader.

Addressed above.

Steve> Of course people have called Emacs a "work environment".  Fine.
Steve> When people ask for an editor don't reply with a "work
Steve> environment".  Especially one where most of its die-hard fans
Steve> will admit takes quite a bit of customization to even be
Steve> moderately productive.  They asked for an editor, not a
Steve> practical project to learn Lisp.

That's just ridiculous. Most people I know who use Emacs couldn't
write a line of ELisp on their own, and the majority of those probably
fall into the die-hard fan category that you mention. It's certainly
not true that you have to customise it from head to toe in order for
it to be useful, just like it doesn't take a bucketload of
customisation for a vi user to be able to be productive in vi. It only
makes sense to customise an application, any application, when you
know it well enough to know what you want and what you don't want, and
beginners don't.

As for the language issue, which you also complain about in another
post, a language that's practical to write scripts for an editor in
must contain a lot of features to manipulate strings, buffers and
whatnot in order to be useful, and many of these things do not make
sense outside of an editor. Therefore it's not very likely that stuff
written especially for an editor will likely be useful outside of that
editor. Having had a look at some of all the scripts that have been
made for Vim, which is probably the most popular incarnation of vi
(certainly, by the sound of it, in this NG), I doubt that any of that
will see use outside of the editor itself. What's more interesting, it
looks like the vi camp is starting to chase Emacs, because the things
that are being implemented for Vim is exactly what we've been doing
all along for Emacs. Ironic, isn't it?

Martin

- -- 
Homepage:       http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj4V1RsACgkQYu1fMmOQldV5WwCg2V0P+GP7C/eKFXTaiWI6uaqP
DHAAoM+NZHxV7RoKhf5TnXg2Xt6tg6r9
=rCSQ
-----END PGP SIGNATURE-----