[IPython-dev] Line-based frontends - architecture

Aaron Meurer asmeurer at gmail.com
Thu Feb 7 20:14:14 EST 2013

On Feb 7, 2013, at 5:34 PM, Thomas Kluyver <takowl at gmail.com> wrote:

On 8 February 2013 00:19, Brian Granger <ellisonbg at gmail.com> wrote:

> But the double meaning of enter in the terminal based IPython is not a
> deliberate design choice - it is only due to the limitation of the
> terminal.  Put another way - If the plain readline based terminal was
> able to detect shift-enter keyboard events, regular IPython, from day
> 1, would distinguish between enter (newline) and shit-enter (run
> code).  Trying to override the meaning of enter to be two different
> things is not something we want to ever do unless we are absolutely
> forced to.  Case in point - I have some private code that starts to
> implement a console style web UI for IPython - it still uses
> shift-enter to run code and the user experience is great...

Counterexample: the Qt console. We can distinguish enter with modifier
keys, but we choose to use the automatic execute/newline. Ctrl-enter forces
a newline, overriding the automatic decision.

For a console interface, where you're usually entering single lines of
code, I think this behaviour is desirable. Every REPL I can bring to mind
follows this pattern, whereas if it was merely a limitation of the
technology, I would expect people to have long since worked around it.


So really you would just want to swap Enter and Shift-Enter in a web
console. The point is that executing is the default. It has nothing to do
with it being forced to also mean newline based on the context.

Aaron Meurer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130207/7bb7f691/attachment.html>

More information about the IPython-dev mailing list