Wed Mar 26 15:47:27 CDT 2008
Gaël explained me a little what was a readline. Now I better understand how
it interface with a gui.
(Please any GUI programmer correct me if I'm wrong, especially for cocoa or
* ANSI color escapes:
In a gui we use a widget that has methods to color the text it display,
depending on the widget used, the methods are way different.
When I interfaced wx to ipython, I sended a string to ipython shell and it
sent back (via readline interface?) an ansi color escaped string.
I had to parse it and process it to make it appears the way it was expected.
>From my point of view I don't expect readline to manage to handle my widget
I mean, send me the data the way I can process it and I will be happy.
Readline must be (I think) GUI agnostic.
Now we can discuss how you can communicate the data. It would be really cool
to be able to select an output object. For example, we could select to set
readline output as escape character OR for example (if we want to handle
bolt etc easily) as HTML output.Why html? Because some widget on WX can get
HTML and display it as is.
We can imagine also XML output or whatelse a GUI guy would need.
If ipython1 manage it by itself, I'm not sure readline should manage it too.
Or does it provide more functions?
>From what I understood from Gael, readline is the object that manage
What I needed when I wrote Wx shell for ip0, was:
getHistoryBack(),getHistoryWidth(),getHistory() etc... in fact function that
can provide me a way to get and manage history strings.
So if we could define a simple interface to readline that could be good.
One important point, gael tells me that usually readline get all character
received from a frontend and it handle it.
I think, (perhaps I'm wrong) that from a GUI designer point of view, I would
greatly prefer to send to readline full string instead of character. Key
event handling is tighly managed by gui itself, so I think it is a little
complex to send it to readline with readline being GUI agnostic...
Well I think we will have to discuss this point. QT/Cocoa guys, what do you
think about this? Perhaps the solution is to create a wxreadline that will
be a thin wrapper between wx key event and readline processing?
Don't have a real solution there...
Be careful, I was speaking from a GUI designer point of view, from a shell
frontend point of view I understand the way that readline process char by
char the data...
So that why, if you explain the advantage of calling readline each time a
char is processed, I will be willing to try to use it like a shell frontend
designer would.(to have a unified interface)
De : firstname.lastname@example.org [mailto:email@example.com] De
la part de Jörgen Stenarson
Envoyé : mercredi 26 mars 2008 19:09
À : IPython-dev List
Objet : [IPython-dev] pyreadline
I have been thinking about the future of pyreadline considering the work
* ANSI color escapes. In trunk ansi color escapes are used to handle
color in prompts. This is convenient(for the programmer) when the
terminal understands these escapes. But on windows this is not the case,
I imagine a few of the guis proposed for ipython1 would also have
trouble with them. In pyreadline we have code for parsing this. So it
would probably make sense to have this functionality available for
ipython1 as well. From a users point of view I think we should consider
figuring out a way that is easier to understand and expand for the
future. We could include ways to use boldface, italics, underline etc.
* I know Gael is looking into using pyreadline for some gui interface
this means there will be even more dependency of ipython on pyreadline.
Perhaps this even means we should add pyreadline to ipython1.
* Completions. Parts of the tab-completion code in ipython could
probably be made to work in pyreadline directly making it useful at a
normal pythonprompt as well.
There is a ton of work I would like to do in cleaning up the codebase
and improving the test coverage. Going with nose here just as in ipython
makes sense. Converting the documentation to rest format using sphinx
looks like a good idea as well.
IPython-dev mailing list
More information about the IPython-dev