[IPython-dev] Line-based frontends - architecture

Mark Voorhies mark.voorhies@ucsf....
Thu Feb 7 18:49:59 CST 2013

On 02/07/2013 04:33 PM, Thomas Kluyver wrote:
> On 8 February 2013 00:19, Brian Granger <ellisonbg@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

ctrl-j = eval-print-last-sexp
in Emacs Lisp Interaction mode (e.g., *scratch* buffer) is a possible counter to the counter.

I think this would follow Brian's argument that a deliberate execute command
is useful in a shell that can handle rich editing.


More information about the IPython-dev mailing list