[Idle-dev] IDLE plans

[Guido van Rossum]

Welcome to the IDLE-DEV mailing list!

We have great plans for IDLE, and we plan to work with all of you into
making the new IDLE a big success.  (I know some of you are working on
your own Python IDE; I'm happy to share sourcecode and ideas, and of
course IDLE will be released as open source as part of the Python core
distribution, meaning it will have the same license as the rest of
Python.)

Jeremy and I had a brief strategy discussion, and we came up with a
bunch of things we should tackle first.


THE DEBUGGER

We want to move to an approach where when you run your program, it
runs in a separate, fresh process.  This means that we'll have to come
up with a remote debugging protocol (which will be part of the
standard Python library, for general use).  I believe effbot has
already done something like this for PythonWorks -- Fredrik, care to
share your secret?  The rest of the debugger needs to be overhauled as
well; see the TODO.txt file in the latest IDLE distribution for more
suggestions.

We discussed breakpoints; the conclusion is that breakpoints ought to
be stored in a (per-project) global "database".  They also ought to be
displayed in the source code window in some way.  When you edit a file
and move code around, the breakpoints should be recalculated and
stored back in the database.

This is going to be a major project.


PROJECT MANAGEMENT

We need project management (again, PythonWorks is a good example; but
so is VC++ or any number of Windows apps).  This is relatively simple
and straightforward.  Question: should there be a 1-1 correspondence
between projects and directories?

We discussed IDLE's current tendency to create lots of top-level
windows, versus a more "pane-oriented" approach.  We couldn't reach a
conclusion, except that pane-oriented should probably be an option.
We decided to put off coding the pane-oriented version.


CUSTOMIZATION

IDLE really needs some better customization (the first post to this
list was about that!).  I propose the following:

(1) A config file containing the major settable options; the user can
simply edit the file to change color preferences, bindings, etc.
Possibly some configuration may be overridden by a per-project config
file as well.  (We *could* use the standard X11/Tk options database,
but this is awkward to use in my opinion, and only works on Unix.)

(2) (Later) a GUI for editing the preferences.

Note that this approach is similar to what we used for Grail (remember
Grail? :-).  This time, however, I'd prefer to use ConfigParser.py to
parse the options file rather than rfc822.py.


NITS

We'd like to make IDLE's Emacs emulation more like Emacs (see TODO.txt
again).  We could use some help in coding this up, and also could use
some suggestions about what are the most sorely needed Emacsisms.  (We
already know about paren matching. :-)

Also, almost everything in the TODO.txt file is still on our list...


--Guido van Rossum (home page: http://www.python.org/~guido/)