[IPython-dev] Splitting inputs, cell inputs in an IPython client

[Dino Viehland]

Thomas wrote:

On 18 July 2013 04:13, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:
So my question is then - what do you think the best way to map this into
our REPL running in VS is?  We already have logic for detecting if a statement
is complete.  It's similar, but we never allow multiple complete statements in
a row ('cell' mode I guess).

The two different modes are not as significant as they used to be. Both can allow multiple complete statements in a single block of input. Of our own clients:
- In the terminal, as you enter each line, it tries to determine whether the block of input is complete. If it is, it sends it for execution, and if not, it gives you a continuation prompt.
- In the Qt console, hitting return at the end of a line works like in the terminal, but you can override it with shift-return/ctrl-return to force a newline or force execution. At present, the completeness checking is done by running the InputSplitter code in the frontend, but see below.
- In the notebook, none of this happens, and you need to use an explicit shortcut to execute a cell.
[Dino Viehland] Ok, we do also have explicit line break commands and submit commands available, I'll look into how we can best map this in our console.

Or, option 2 we could send the text across the wire to IPython, and ask if IPython
thinks that the input is complete.  That would allow IPython to be in charge, and if
you evolve this behavior, or there's some way for users to provide their own line
splitter, then we'd get the latest and greatest behavior.

I do intend to add this to the protocol, and make the Qt console use it. Part of the rationale is that we want to add a web console that's neatly integrated with the Notebook, and our current InputSplitter code can only be used by Python-based frontends.
[Dino Viehland] Do you know when this will happen?  We can certainly do our own parsing for now and then switch over whenever this becomes available.

> I think #1 is
> probably actually easier to implement for us and result in a better user experience.  For
> example if the remote IPython process has become unresponsive or crashed the user
> will have a slow response time because we're querying for the complete input on the
> UI thread.
It will need some care, but I think it should be doable. We already do tab completion by exchanging messages with the kernel.
[Dino Viehland] Good point, we do the same, and those happen a lot more.  Thanks for the feedback!
Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130719/b248bb47/attachment.html>