[IPython-dev] pyreadline

[Laurent Dufréchou]

Hi jorgën,

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
QT)

* 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
display.
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.

*Completion:
If ipython1 manage it by itself, I'm not sure readline should manage it too.
Or does it provide more functions?

*History
>From what I understood from Gael, readline is the object that manage
history.
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)

Laurent

-----Message d'origine-----
De : ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org] De
la part de Jörgen Stenarson
Envoyé : mercredi 26 mars 2008 19:09
À : IPython-dev List
Objet : [IPython-dev] pyreadline

Hi all,

I have been thinking about the future of pyreadline considering the work 
  on ipython1.

  * 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.

Jörgen






_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev