Best Python editor (under Linux)

[Bengt Richter]

On Sat, 04 Jan 2003 19:55:29 -0000, Steve Lamb <grey at despair.dmiyu.org> wrote:

>On 4 Jan 2003 15:40:04 GMT, Bengt Richter <bokr at oz.net> wrote:
>> Ok, now suppose tme.py when run as a program started an interactive shell
>> that presented a nicely featured editor, which happened to have some simple
>> editing features you wanted for composing email or news posts, etc., so the
>> basic composition problem was solved. Would you build on this interface? 
>
>    No.  Furthermore I'd rip it out of the module to converse space.  The
Well, with the Python version you could do that, and with the functionality
already factored as I sketched it, i.e. into tme.py general purpose stuff
and an interactive editor based on it, the likelihoood that they would be
one file instead of an editor script importing the tme.py stuff would be low,
so you wouldn't have to rip it out ;-)

>proper way to do things is to create the application and /call the editor/.
But if your application is mostly special-purpose editing, you can't just
call an editor, except to do trivial message body editing like you'd get from
notepad.exe. You may have a point, that it might be nice to let people use
whatever they like for _that_ part. I'm sure both vim and emacs could create
a temp file and run notepad or any other editor on it, as an option ;-)

But the special purpose editing like parsing headers and automating replies and
pasting with quote annotation etc, are not available in notepad. So you can
see the temptation of building on an infrastructure that already contains the
primitives that make implementing those things easy. Why reinvent those wheels,
except for fun, maybe, if most of your intended audience is already using
the same infrastructure (as I would guess the situation probably was when emacs
gained some of these extended capabilities)?

IMO it's more natural to view an email client as a special purpose editor, than
to view it as a communications program with incidental editing requirements.

I'm all for clean factoring, but programmers are "lazy" and will go for easy wins
in functionality. Ideally, the full power of emacs or vim infrastructure would
be available factored out into library modules (python, naturally ;-) so you could
build something new with exactly what you wanted, and no more. But my guess is you'd
want a good deal of it.

>Why?  Because everyone, as this thread has proven, has their own favorite
>editor.  Forcing them to use what you think is best is unintuative to pretty
No one is forced to use a new email client or whatever. If you can't build an
interface you think is better than the status quo, how is anyone going to
get to experience anything new?

>much everyone but you and a waste of a lot of programming time now and in the
>future.  Why?
>
>    "Gee, editor foo can do feature bar, can you include it in your mail
>client?"  
 
Answer 1: "Fortunately this mail client is based on the infrastructure library of
a powerful editor, so you can have what you want. Did you read about key bindings
and scripting in the docs? You can do it yourself, if google can't find something
readymade for you."

Answer 2: "Sorry, editor foo wasn't designed to integrate into anything, so you
can choose that editor, but it won't be able to operate on anything but the
content of your messages, and nothing can be inserted automatically from the
rest of the client context, and we didn't have time to implement extensive scripting.
Sorry."
>
>    I've seen it far too many times in nearly a half dozen email clients in
>the past 10+ years to ever want to fall into that mistake.  Ever.
>
Ok, I should not ignore your cries of pain. I haven't had to deal with any of that ;-)

Regards,
Bengt Richter