schanzer
commented
3 years ago I absolutely love that this issue is being raised so thoughtfully! On a related note, it's extremely common in the first few days of PD for teachers to type something in the REPL, click "Run", and then complain that "nothing happened, and all my code went away".
I see the utility of #3 (make the REPL smarter), but the harms outweigh the benefits when you consider the use case of novices who don't really know if something is parseble or not: they start thinking the whole thing is inconsistent and buggy, and lose faith in the editor.
I would be in favor of a small button on the bottom-right corner of the text area, perhaps with some iconography that resembles the run button (even just a tiny blue "run"!). That would make it clear that there's a difference between "run" in one context versus another.
This would allow the normal Enter/Return key behavior to insert a new line.  and while, we could have a tool tip that appears when someone hovers over the embedded run button, showing them that shirt-enter will serve the same purpose. (FWIW, I wish I was a major buttons in the editor had tooltips revealed these shortcuts!)
sorawee
Until I saw #387, I didn't think the Pyret REPL allowed multi-line entry. I'm used to either enter or cmd+enter allowing multi-line entry, but it seems like shift+enter is the way to do this in CPO.
I'd like to make that more discoverable or start a conversation about changing it.
Suggestions
1. Add to the keyboard shortcuts modal
I don't think this would really help, but it seems like a minimal requirement for a feature like this.
2. Add "did you mean to type more?" to the error message for incomplete statements.
When you hit "enter" wanting to start a second line, you currently get an error message that is reasonable if you had asked to compile a whole file, but is probably not helpful if you just wanted to keep typing:
Could the CPO runtime look for this message after REPL executions and prepend a "did you mean to use shift-enter to keep typing?" message above it?
3. Make the REPL smarter?
On enter, if the parse is incomplete, we could just swallow the error and insert a newline and appropriate indentation. (This would rely on knowing if the parse problem is in the middle of This behavior is common in industry REPLs, but implementing it naively might also be swallowing errors that the student really does want to see?