Gary Bishop wrote:
> I *can* make color work on Windows with my Python port of GNU Readline
> but it will require changes to IPython. Specifically, I need to get
> access to everything that IPython prints before it goes out. I tried
> replacing sys.stdout with a "file like" object but IPython doesn't
> want to play with that for reasons I don't understand. Probably a bad
> idea for a shell to fool with that anyway.
>> So, if internally IPython had a function console_print or whatever,
> normally it would just print but the windows version could eat the
> escape codes (I've got that part written) and tell the Windows console
> to do the right thing.
Ipython prints all output via the Prompts classes. Take a look at that file,
it's fairly simple. It uses the fact that python itself honors whatever is
hooked into sys.displayhook:
ipmaker.py:678: sys.displayhook = IP.outputcache
where:
ipmaker.py:650: IP.outputcache = CachedOutput(IP.rc.cache_size...
and CachedOutput is a class defined in Prompts. You'll see that this class
already has a display() method implemented by default as _display, but you
could overwrite it as needed with your own methods under Windows.
The whole point of this design is to make it possible to overwrite these
methods to satisfy specific needs without actually changing ipython's code
itself too much.
Obviously, if you find that the current architecture _prevents_ you from
conveniently putting in the hooks you need, I'm happy to make any necessary
changes. But before we go into trying to change ipython itself, let's see how
far we can get by properly subclassing/overriding methods at runtime.
You could start playing with this as a profile, which at startup time modifies
the display() method with whatever you need. This would be a user-level, 100%
unintrusive modification. If it passes the test of some extended use by you
and others, it becomes trivial to fold it into the ipython codebase to be
loaded at startup under Windows.
Thanks for this work, and keep us posted.
Best,
f.