IPython ToDo list
=================

This document has been superceded by new_design.lyx (there is a PDF version of
it included in this same directory).

  
TODO - Done or mostly done
----

- Merge xcolor and prompt_color into a single color scheme option.

  * DONE

- Make @prun->@run and remove old @run. Currently @prun and @run aren't really
orthogonal enough to warrant keeping both.

  * DONE

- Document well. Ideally, have a single source file (lyx) and make html, ps,
pdf, man and runtime info from the same place.

  * Mostly done, though the manual can always be improved. No man-page yet,
  though.

- Packaging: put it all together in fewer files and setup a distutils package
structure for easy distribution/installation.

  * DONE

- help: now we have help with both help() and ?. Is it worth it or is it
better to unify them into a single one? The '?' system seems to roll its own
help documenter while 'help' uses pydoc, now a standard. But the '?' syntax is
great. Maybe we could keep the '?' syntax but simplify/unify the underlying
engine.

In fact, I think the best would be: keep both, with help providing
'heavy-duty' access to the manuals with paging, and ? as a quick access to
docstrings and object info. We should add the definition line(s) of any
callable to the information printed by ?.

  On the help topic: make ?@anything work. Now it doesn't crash anymore, but
  with the current magic self-documenting infrastructure, it's trivial to
  modify the helper to print the docstring for magics if called with ?@...

  * DONE.

- One last feature I'd like to add: the magic_oinfo() function, to work also
with the object?? and ??object syntax. Using the inspect module it would be
fairly straightforward to write a very nice/useful object inspector for
run-time use. It should show: object type, value (snipped for length),
namespace, file of definition, interface (for callables). And offer options to
view full printouts for long objects and directly view source files for code
objects.

    * DONE


- color prompts? I tested Nathan's but I do get the weird behavior at the end
of the line. 

   * DONE


- LazyPython: add the great syntax (,/ and barewords) of pythonstartup,
incorporate the many functions defined there. Decide whether to make them
@magic. I tried to bring it in but it seemed to conflict too much with ipp's
shell class. The integration of the two might require more surgery than just
cut'n'paste.

  * Status: the shell functions are a module available via the cmd line option
  * -ShellServices. But the nice LazyPython syntax remains to be integrated.

  * DONE (Nov/2)!!! Now LazyPython behavior is available. Yes!!!


- Fix history substitution, which is a bit clunky. We should have what emacs
or tcsh give: once a few letters are written, the arrows (or ^p/^n) only move
in the subset of history items which begin with those letters. And document it
well.

  * Status: DONE (it was a simple readline parse_and_bind thing)


- @magic and ShellServices? These two systems seem to duplicate a lot of
functionality (especially with the automagic option). A decision needs to be
made, and a single, clean interface offered.

  * DONE: removed ShellServices altogether. @magic can take care of this
  * pretty well, and if someone *really* wants extra stuff, they can always
  * load their own. But let's try to keep a reasonably clean design here.


- Harmonize config file and command line options. They should both provide
access to all the same options. Then, change _ip so that _ip.rc is the config
file info only and _ip.opts is the command line info only. Right now those two
things are manually synchronized in a flaky, confusing manner. When new
options are added, the current setup requires manually checking that all is in
sync so that session log/restore works. PITA.

The best way to do this is probably to define _ip.rcfile as what gets read
from rcfiles, _ip.opts what comes in the cmd line (do away with _t.opts) and
then do: [ _ip.rc=Struct(_ip.rcfile);_ip.rc.update(_ip.opts) ]. This way any
keys that are added get auto propagated throughout. Replaying _ip.opts should
be enough to reconstruct any session (since that would keep the original info
about how it was invoked).

   ** Mostly done. Command line/rc code is much cleaner now. Not
   ** perfect, but not the maintainability nightmare it had become either.

- Parametrized aliases: extend the alias system to allow:

      >>> @alias al cmd -a -b $1 foo bar $2 spam $3 eggs
would define a magic @al such that 
      >>> @al AA BB CC
would give the system call
      cmd -a -b AA foo bar BB spam CC eggs

Not hard, just be careful with the dynamically generated regexp code
necessary.

  ** DONE. Not quite with numbered arguments, only strictly positional (%s). It
  ** was quite tricky to write and I think it's useful enough. Later could be
  ** improved to numbered args.

- Implement input history with variable access (currently only keyboard and
search access). Bind _i<n> input lines/sets of lines. This isn't multi-line
editing yet, but at least would allow one to do some more dynamic work with
code (e.g. 'exec _i4'), and easy copy/paste of code written in IPython into
editors (without the prompts).

Maybe change _p to _o to have _i for input, _o for output. (?)

  ** DONE.

- add @continue command. After program inside ipython stops, @cont would catch
where execution stopped from a specific exception (say honor only SystemExit,
or even a special purpose exception), and resume running at that point (like
IDL does). Great for 'debugging' without loading a full debugger. Or maybe it
would be worth integrating the debugger into it (?)  @continue is tricky..

  ** DONE (sort of):

  This has been sort of solved, 'in reverse'. With the recent addition of the
  embeddable IPython, one can call an IPython shell inside other code as
  needed. This basically takes care of what I had in mind, without needing
  fancy, strange traceback frame handling or any black magic.
