<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 February 2013 00:19, Brian Granger <span dir="ltr">&lt;<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1n5">But the double meaning of enter in the terminal based IPython is not a<br>
deliberate design choice - it is only due to the limitation of the<br>
terminal.  Put another way - If the plain readline based terminal was<br>
able to detect shift-enter keyboard events, regular IPython, from day<br>
1, would distinguish between enter (newline) and shit-enter (run<br>
code).  Trying to override the meaning of enter to be two different<br>
things is not something we want to ever do unless we are absolutely<br>
forced to.  Case in point - I have some private code that starts to<br>
implement a console style web UI for IPython - it still uses<br>
shift-enter to run code and the user experience is great...</div></blockquote></div><br></div><div class="gmail_extra">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.<br>

<br></div><div class="gmail_extra">For a console interface, where you&#39;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.<br>

<br></div><div class="gmail_extra">Thomas<br></div></div>