[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.
Thomas
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