[IPython-dev] smart indent, multiline statement history and multiline statement edition

Fernando Perez Fernando.Perez at colorado.edu
Tue Dec 27 02:02:11 CST 2005


Hi Vivian,

continuing to catch up with my gigantic backlog...

Vivian De Smedt wrote:

> In my quest to contribute I would like to improve IPython in two areas:
>  - copy and paste
>  - multiline edition
> 
> 1.) By improving IPython for copy and paste I mean try to find a way to 
> paste multiline statement when autoindent is on.
> What I had in mind is the following:
> 
> Since autoindent is pretty enough to propose you identation each time 
> you could need one or to say it differently when autoindent is on the 
> tab touch is unnecessary I propose a smartindent mode (which could just 
> the autoindent mode if you like it).
> 
> In that mode the autoindent proposition of leading space is forgotten if 
> the first character of a line is a space or a tabulation.
> 
> In such mode autoindentation is working more or less the same way as 
> before but if you copy a bunch of code from elsewhere it will be paste 
> with the original indentation.
> 
> Let me know what you think about this proposition, if you did try such 
> aproach in the paste and if so what was the techincal difficulties you 
> faced (I guess here the various implementation of readline will play 
> they role and I will have to test my patch against each of them before 
> submision).

OK, I couldn't quite convince myself whether this was easy, possible but hard, 
or plain impossible.  In trying to give you a decent answer, I ended up just 
implementing it, sorry :)  It's now in SVN.

Note there is still a caveat: you can now paste code, but it still looks wrong 
on screen and in the readline history.  This due to limitations imposed by 
readline, and I can't fix that.  But the pasted code is interpreted correctly, 
and the internal history (non-readline) is OK as well.

Please test it, and let me know of any problems.

> 2.) I would like to improve multiline support. I have various ideas some 
> modest some more ambitious.
> 
> The first is just about the history of the command. Now when you type a 
> multiline statement each line of the statement is a separate entry in 
> the command history.
> 
> def foo(bar):
>     bar += 3
>     return bar * 2
> 
> However the chance that you are interested by the line "    return bar * 
> 2" by itself is not big.
> 
> My proposition was that only the first "def foo(bar)" was visible in the 
> command history and that when you choose it (hit return) the next one 
> ("    bar += 3", "    return bar * 2") appear in the forward part of the 
> history such that you can quickly review a multiline statement.
> 
> Here is a small scenario illustration the usage of my proposition:
> 
> def foo(bar):
>     bar += 3
>     return bar * 2
> 
> [up-arrow]
> edit the first line of the multiline statement
> [return]
> [down-arrow]
> edit the second  line of the multiline statement
> [return]
> [down-arrow]
> edit the third line of the multiline statement
> [return]
> 
> Let me know if it is clear, if you like it, if you think it could be 
> usefull if you think it is feasible.

While in principle I like these ideas, I think that they are impossible to 
implement within the limitations of Python's readline API.  I am not sure if 
the full GNU readline has enough functionality for this to work, but python 
certainly doesn't expose enough of it.

But feel free to prove me wrong with a patch :)

Keep in mind that I am currently trying to flush out all the accumulated 
patches, questions and contributions to ipython for a .16 release, so that I 
don't ignore what you and many others have done over the past few months.  But 
all real new development is taking place in the chainsaw branch (not really 
functional for interactive work yet).  This will eventually provide an ipython 
'kernel' which can be easily embedded, for example, in a GUI or in a curses 
environment, where decent multi-line editing becomes much more natural.

Once I 'pay my debt' to the community by incorporating and resolving all the 
accumulated issues, I'll continue mostly working on moving the new system 
forward.  Still, patches to trunk will continue to be accepted (as long as 
they don't require too much reworking on my part) until the chainsaw branch 
becomes functional enough to fully deprecate the current trunk.

Best,

f




More information about the IPython-dev mailing list