What I want in an editor/IDE

[G. S. Hayes]

Chris Cioffi <evenprimes at gmail.com> wrote in message news:<mailman.673.1090438595.5135.python-list at python.org>...
> I do about 90% of my development on and for Win32.  The rest
> is for Linux and usually done in vim through an ssh login.

You're 10% of the way there.  :-)

> What Komodo has that I really like:
> -Projects - This is the difference between an editor and an IDE for
> me.  The ability to define a set of files as being logically related. 

What exactly does this mean?  I ask that as a serious question.  When
I edit in vim, files are related in a whole bunch of ways:

* tags; if I call a function/method/class from another file, vim will
automatically jump me to that file when I hit Ctrl-] on the call and
jump me back to where I came from when I hit Ctrl-t (just build a tags
table with "ctags *.py" beforehand).
* Sessions; if you save a session, next time you restore it vim will
open the same files, buffers, etc, loading each file into its own
window, putting the cursor on the same line number in each file,
setting up all your bookmarks and options as they were, etc (use
mksession for this)
* views and folds; you can save and restore multiple views on a file
with mkview.  Folds give you another way to navigate around logically
related functions in a file without feeling like you have a huge
monolithic file.
* Directories; the os-level way of defining a set of files as
logically related

and probably others that I can't think of at the moment.

I'm curious as to what moving away from the file concept really buys
you, other than making it harder to use regular tools on your python
files (outside the IDE).  To me, a good editor works *with* the file
concept (making it so you don't need to do file management, specify
individual filenames to edit, etc, but at the same time integrating
well with the rest of the OS tools).

> -Debugger 
vimsh + pdb

> -Simple (one or two key/click) way to run the program I'm editing

You'll have to define the program name in each session (once), but
after that mapping a key to run it is easy.

> -Syntax completion (Kinda...)

Vim will complete on tags (ie class/method/function names),
words/phrases in the current window/buffer/session, user-defined
dictionaries, /usr/dict/words, etc.  You can configure which of the
above to use and in what order (or even map multiple keys to different
setups)

> -Post run access to the command interpretor.  Basically, after my
> program crashes, I'd like to be at a place where I can do a little
> digging on variable state, etc.  This might just be my need to learn
> more about pdb and start using it.

vimsh + python -i, or pdb.

> -Built in, syntax aware, spell checker.

vim has none built in, but it does syntax highlighting (which will
visually catch some typos) and integrates tightly with external spell
checkers.

> -Code/class browser, should be doc string aware

Vim will e.g. open a small preview window with the called method and
docstring displayed in it, among many other things; not sure exactly
what you're looking for.

> -The ability to import/export all settings from another installation.

Trivial with vim

> -Sophisticated Python aware syntax highlighting  Beyond just "this is
> a string".  I'd like to have highlighting distinguish between doc
> strings, normal strings and triple quoted strings.

Vim can distinguish regular strings, triple-quoted strings, and raw
strings (and Unicode strings, etc), but I don't think it
differentiates docstrings.

> -Ability to work through an SSH shell

Vim runs in a GUI window or on console, so this is easy.  Either X11
tunnelling or fall back to console mode.

> -Ability to build extensions in Python would be slick.  
Vim does.

> -Built-in UML to code outline builder.  At least a graphical code
> structure designer.  (At the object/function/module/package level.)

Nope, and I have no experience with alternatives here.

> -GUI designer?  With all the GUI tool kits/langauges this might not be
> reasonable except as a plug in...

I use glade for this.

> -Support for version control systems.  This probably needs to be a
> plug in kind of thing so it can support CVS, Subversion, et al.

There are Vim packages for both of those (among many others)

> What features do you think make a great coding system?

#1 It should be a UDE (Unintegrated development environment), so that
you can easily replace pieces (debugger, GUI builder, compiler, etc)
without changing the rest of your toolchain.  Ideally it should be
easy to make all the pieces work together transparently but still easy
to replace them with alternatives.