[IPython-dev] Line-based frontends - architecture
Mark Voorhies
mark.voorhies at ucsf.edu
Thu Feb 7 19:49:59 EST 2013
On 02/07/2013 04:33 PM, Thomas Kluyver 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
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.
--Mark
More information about the IPython-dev
mailing list