Interactive Python programming in ... vi [was: Tab wars revisited]

[Martin Christensen]

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

>>>>> "Steve" == Steve Lamb <grey at despair.dmiyu.org> writes:
>> Emacs allows me to interact with a continuously live instance of
>> the Python interpreter.
Steve>     You know, oddly enough this isn't something I demand of my
Steve> editors.  With things like screen, konsole, multiple rxvts or
Steve> even plain old ALT-F1, ALT-F2 I get the exact same
Steve> functionality.  It's called learning how to use the tools given
Steve> instead of insisting on having everything bolted onto one large
Steve> bloatware application.

You know, it strikes me as odd that you are so quick to dismiss the
usefulness of something you have not tried in practice. I have tried
it, and I very much miss it when it's not there.

As for the whole 'bolted on' thing... being able to interact with
another process is useful for a wide range of things, as I'm sure any
purist vi user will agree. Also vi can run such processes, sending
input to them and doing something with the output. This particular
feature of Emacs' is simply having input to and output from the
process in the same buffer, and it's reused widely. I've already sung
the praise of its usefulness for interactive programming in Python and
similar languages, but I've also found it invaluable e.g. for
interacting with SQL databases (anyone who've used Oracle's sqlplus
can surely quickly be persuaded of this), where the output is
something that you'll often want to fiddle around with in your editor
anyway. Well, at least I do.

Now, if it's possible to run a Python process separately from vi which
you can send code snippets to anytime, then you can conveniently have
your small, separated tools and the functionality that Jacek and I are
so fond of at the same time.

As for the whole bloatware argument, I think it's getting a bit
ridiculous. Fine, I build Python into Vim, and I'm all for that. I'm
sure that means that I can hook into a _lot_ of Python code that way,
thus making Vim every bit as much bloatware as Emacs is. Seriously, if
you want a slim Emacs, don't load all the things you won't need. Sure,
you'll never cut Emacs down to the minimum size of any vi
implementation, I'm sure, but it was never designed for extreme
compactness. At the computer science department I very recently
graduated from (yay me!), Emacs was used significantly more than vi on
our application servers, and none of our application servers have ever
had scarceness of resources because of it. Sure, on a mobile phone or
PDA with very limited resources, I might start to worry about size,
but with even relatively low-end machines having at least 256 MB main
memory these days, fussing over a couple of megs for something as
important as the text editor one uses, which is probably in the top
three of the most important programs people like us use, is nothing
but pedantry. If that's what's going to tip over your box, it's time
to put the old 386 out of its misery. Hell gVim compiled with Python
support alone takes up 7.5 MB at startup on my box compared to Emacs'
8.2 MB with my own 'basic' stuff loaded (which is quite a lot for
some). Is it really a big deal? It certainly isn't to me.

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.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD4R+AACgkQYu1fMmOQldWB8ACg5GMNmMhC2IALb62dhMlu8dRh
hJwAnjengArZINHPWOIYcXRuIqcFT+pu
=32eg
-----END PGP SIGNATURE-----