[Feature request] Shift-enter in the REPL?

[sorawee]

DrRacket currently uses submit-predicate to determine whether an "enter" should submit the expression for evaluation.

The issue with submit-predicate is its inflexibility. Sometimes we might want to enter multiple lines, but the first line is already deemed "terminating" by submit-predicate, so doing so is not possible. One possible workaround is to allow multiple lines by default and let users enter twice in a row to indicate submission, but that is also not ergonomic when users want to enter only one line.

But there is another model, seen in notebook applications (Jupyter) and messaging apps (like Slack, Facebook Messenger). There are two keys: shift-enter and enter. One submits the input unconditionally. One simply adds a newline without submitting the input. I find this to be more flexible, and the language creator doesn't need to concern with submit-predicate anymore.

[sorawee]

Accidentally submitting while there's an unmatched paren might not be ideal though. So submit-predicate could still be useful. Still shift+enter could override submit-predicate so that the answer is temporarily #f while inserting a newline char, and I think that's still useful.

[shhyou]

I second similar features but for command-line REPL as well.

[rfindler]

I believe this is alt-return on a mac, but I see that the keybindings dialog doesn't really show a different name for the two keystrokes.

[mflatt]

It's similarly Meta-Enter for expeditor. I'm not sure whether expeditor can get shift-key information, but it doesn't look like it in the case of Enter.

[sorawee]

I can use Meta-Enter in expeditor, and I'm happy with that.

I couldn't get alt-return to work on Mac. What's the name in the keybinding dialog? do-return?

[rfindler]

What's the name in the keybinding dialog? do-return?

Looking at the code, it looks like this doesn't go through the keybinding functionality, but uses on-local-char. It seems like the rules are that if either shift or alt are down, it'll just take the input that's there. If not, it'll ask the language (where the default predicate is "only whitespace following the insertion point".

[sorawee]

Oh, that's the opposite of what I want though. I want a way to not submit, even though submit-predicate thinks that it's ready for submission. Meta/Alt-Enter in expeditor does exactly this, which is what I want.

Meta/Alt-Enter in DrRacket on the other hand is a way to force submission, even though submit-predicate thinks that it's not ready for submission.

I can see that Meta/Alt-Enter in DrRacket could be useful too, but I think Meta/Alt-Enter in expeditor is more useful.

The fact that Meta/Alt-Enter in DrRacket and expeditor disagree in the completely opposite way is really unfortunate, and confusing.

[rfindler]

Oh, I see! I was confused.

I'm torn. On one hand, I am happy to change DrRacket as I agree this is a standard thing these days (although I would prefer to know that it is standard across a bunch of other places). On the other hand, there will certainly be people who will be unhappy with this kind of a change, as their fingers are trained a certain way; DrRacket has been like this for longer than it has had the name "DrRacket", I'm pretty sure.

[sorawee]

To recap and to make things clear for anyone that follows this:

In DrRacket, type ( in the REPL.

• Pressing enter would not submit ( for evaluation, since submit-predicate determines that the input is not ready for submission.
• Pressing alt+enter would submit ( for evaluation, resulting in "read-syntax: expected a ) to close ("

In DrRacket, type 1 in the REPL.

• Pressing enter would submit 1 for evaluation, since submit-predicate determines that the input is ready for submission.
• Pressing alt+enter would submit 1 for evaluation

In expeditor, type ( in the REPL.

• Pressing enter would not submit ( for evaluation, since submit-predicate determines that the input is not ready for submission.
• Pressing alt+enter would not submit ( for evaluation

In expeditor, type 1 in the REPL.

• Pressing enter would submit 1 for evaluation, since submit-predicate determines that the input is ready for submission.
• Pressing alt+enter would not submit 1 for evaluation.

[sorawee]

Can we have

• Enter: let submit-predicate determine whether to submit
• Alt-Enter: unconditionally submit (compatible with DrRacket)
• Shift-Enter: unconditionally not submit (compatible with chat apps) ?

[rfindler]

@sorawee sorry I'm returning to this so late.

There is also one other dimension to consider, namely return vs enter. I think the keystrokes you're asking for are actually return-based ones, not enter-based ones. That is, you're asking about the key that's usually above the shift on the right-hand side of the keyboard, not the key that's on the numeric keypad (on my keyboard the former is labelled "return" and the latter is labelled "enter"; I'm using one that looks like this)

Run this code to see which key is which from drr's perspective:

#lang racket/gui
(define c%
  (class canvas%
    (define/override (on-char evt)
      (unless (equal? (send evt get-key-code) 'release)
        (printf "> ~s\n" (send evt get-key-code))))
    (super-new)))
(define f (new frame% [label ""] [width 400] [height 400]))
(define c (new c% [parent f]))
(send c focus)
(send f show #t)

You're talking about the ones that print out as #\return right?

If so, then I'm in favor of this change.

[sorawee]

Yes! I have no idea there's a difference between return and enter!

[rfindler]

Well, it looks like @mflatt earlier said that he cannot get the shift-key information in expeditor, but I've pushed the change to DrRacket.

[sorawee]

And currently, alt+return in expeditor is equivalent to shift+return in DrRacket.

One thing that I also just realized is that in iTerm (my terminal application), alt+return in expeditor doesn't even work by default. We need to switch "Left Option key" from "Normal" to "Esc+" for alt+return to work.

[rfindler]

I can confirm that drracket's new shift-return matches discord, slack, and line.