cmd-A in interactive shell should only select text in current prompt

[laszlokorte]

As you can see in the recording below when pressing cmd+a (ctrl+a) in the interactive command prompt all the text in the interactive window gets selected.

Suggestions: it would be convenient if only the text in the currently interactive prompt (only (foo bar 5) would get selected.

Actually the cursor behavior in the interactive window is a bit confusing as you can move th cursor outside the editable line and it's still blinking (suggesting that the text can be edited when in fact it's read only).

Suggestion:

• Limit the cursor movement to the editable prompt
• if the cursor is in the first or last line of the interactive prompt arrow up/down should cycle through previous read commands
• escape key could toggle read-only mode of the interactive window allowing the cursor to move everywhere but disabling the prompt (in read-only cmd+a could select all the text)
• when not in read-only mode clicking anywhere in the interactive window should force the cursor somewhere into the editble region of the prompt (currently when clicking right after the > in the prompt one can not enter any text)

[spdegabrielle]

@laszlokorte great idea! Would you be interested on working on a pr with me?

[laszlokorte]

@spdegabrielle I have no idea how DrRacket is implemented but yeah we can try that.

[spdegabrielle]

@laszlokorte The ‘framework’ library is used by DrRacket for the gui, so looking at the current code is the first step.

I can do a simple gui app that replicates the DrRacket ‘interactions’ editor, that we can use to take this forward. Most of the changes will be adding a new class(or mixin) with the desired functionality to ‘racket/framework’. The PR to DrR should be small. https://github.com/racket/gui/tree/master/gui-lib/framework

[rfindler]

I think the ability to select and copy text from parts of the interactions window that aren't the new prompt is a useful ability. Also, if you type a return at the end of the s-expression of a previous interaction, it gets brought down to the current one.

[laszlokorte]

@rfindler Thats why I suggested the two modes:

1. one in which: the panel acts as a classical prompt where the cursor is constrained to the current prompt line, cmd-a selects online that prompt, up/down arrow cycles through the history...
2. another one in which: the whole window is read-only, the cursor can navigate the whole window, cmd-a selects everything, up/down arrow moves the cursor across lines, the current prompt is read only.

I see the escape key as a natural way to switch between the two modes. Additionally you could have something like: When switching from mode 1 to mode 2, the curser position inside the prompt line is remembered and marked as insertion point. If you switch back to mode 1 the cursor position is restored. If pull down an expression by pressing enter (as you described, I did not know about that) that expression is inserted at that remembered insertion point (instead of at the end of the end of the prompt line) and the panel switches back to mode 1.

[rfindler]

Ah, okay! I missed that. Using esc to get out of the mode might make sense, but it sounds to me like a mode where people wouldn't switch that often (they'd get used to one mode or the other) so maybe a menu shortcut for switching would be better. Also more discoverable.

I think that this would probably have to be implemented as a mixin that accepts a color:text<%> (and probably more but at least that) and then work at the level, using something like the regions concept that it uses (that's how the colorer currently knows which parts are intended to be colored (inputs at the prompt) and which aren't (results and output)).

[laszlokorte]

but it sounds to me like a mode where people wouldn't switch that often (they'd get used to one mode or the other)

Well the one mode is entirely read-only and the other cursor is constrained to the editable prompt line. So I would expect to switch between the modes regularly while working in the interactive window.

Or are you talking about having the current behavior as a third mode?

But yes in addition to the escape key there should additionally be a menu item in the the gui. Also as I described above you would not always have to manually switch modes as the editor could often infer the desired mode by your actions: Eg. clicking into the current prompt line would switch to the prompt mode, clicking on the output of previous commands would switch to edit mode. Pressing enter in read-only mode while the cursor is at the end of a prvious command would switch back to prompt-mode.

[rfindler]

I think that either a mode the user controls or something where certain keybindings behave differently at the prompt makes sense, but probably not both. Happy to discuss either, tho.

[laszlokorte]

I imagine something like this:

[rfindler]

When the insertion point is at the prompt, what are the differences between read mode and prompt mode? I see cmd-a is one. Are there others?

[rfindler]

Also, I'm not comfortable with deviating from the mac human interface guidelines wrt to cmd-a.

[laszlokorte]

For one all keyboard commands for navigating the the text (eg cmd+up would jump to the start of the prompt instead of to the start of the window).

My point is that it's confusing/annoying/unintuitive to have one large text buffer of which only small section is editable and whose behavior (eg pressing enter) differs so much only depending on cursor position. The difference between the cursor being inside the prompt line and being outside should be more explicit.

For example if you run (read-line) you get another type of prompt which behaves a bit more sane: cmd+a selects only the text inside.

I do not see a conflict which the HUI guidelines. The prompt line whould in a way be it's own input field which has focus in prompt mode.

[rfindler]

Oh, if you were to make a nested editor for the prompt I see what you mean. I didn't get that from your earlier messages.

re: confusing/annoying/unintuitive: I think there is probably a simpler approach to addressing that; perhaps DrRacket could highlight the prompt region that it thinks you are in (if there is one), which would be a clue as to how return will differ.

[laszlokorte]

Oh, if you were to make a nested editor for the prompt I see what you mean. I didn't get that from your earlier messages.

Yes kind of, but then where would still need to be a way to move the cursor between the inner and outer editor via keyboard. Eg in case of (read-line) (which causes a nested editor correct?) I can click outside to move the cursor away and unfocus but have no way to unfocus it just by keyboard? And I can not restore the focus to the nested editor just by keyboard only by clicking inside.

re: confusing/annoying/unintuitive: I think there is probably a simpler approach to addressing that; perhaps DrRacket could highlight the prompt region that it thinks you are in (if there is one), which would be a clue as to how return will differ.

In the example flow I drew above the pink region in promp mode could actually be highlighted as being a textfield in the UI.

[rfindler]

Yes, when a function tries to read from the initial value of current-input-port, DrRacket opens a nested editor. For keybindings, open DrRacket's edit|keybindings|show active keybindings and type "emb" into the "search string" field.

[laszlokorte]

Thanks, I did not know about that but by default there are only keybindings for the the definitions window, not the (read-line) editor in the interactive window, maybe that's just a bug?

Still I think the interactive window should be more efficient to use without requiring knowledge about editor hierarchies (which I regard as implementation details of the gui framwork)

[laszlokorte]

Another example to stress my point: In other repls by default simple up/down arrow presses cycle through history. In DrRacket you need to press alt+arrow. But if you accidentally press just the arrow keys or by other means move the cursor out of the active prompt line you end up in a situation where you can not type anything at all anymore before manually bringing the cursor into the correct position. I have witnessed all people I have seen learning racket being bit by this:

1. for whatever reason the cursor get's misplaced
2. trying to type something in
3. why does nothing happen? is it crashed???? confusion

There should always be an insertion point in the current prompt line and trying to insert anything should use that point and return the cursor to it automatically. (compare that with the behavior of macos native terminal when selected some text and then type something in)

[spdegabrielle]

@rfindler @laszlokorte I'm not keen on introducing modes in user interfaces because they make mode errors that are frustrating to users possible. That said, I feel the global select free movement of the cursor in the interactions repl is unusual when you compare to the shell that most users are familiar with.

I wasn't aware of ' type a return at the end of the s-expression of a previous interaction, it gets brought down to the current one.'

Another thing to note it escape already has a meaning in editng (at least for mac users) 'On Mac OS, Meta is, by default, available only through the Escape key.'

I was initially interested in tweaking the repl to

• [ ] ctrl-a select the current line
• [ ] up/down arrow to move through history
• [ ] not restrict select with the mouse
• [ ] if you are keyboard only a currently unused keycombo(alt-arrow?) could be use allow movement off the current line
• [ ] pressing enter wen outside the current line copies the current selected s-expression and returns to the current prompt as described by @rfindler above, or just retruns empty-handed if no s-expression selected.
• [ ] Typing takes you back to the last position on the active line. (as per the frustration mentioned by @laszlokorte above)

Does that sound like an achievable solution?

If you want to go further I'm considering a 'Jupyter Notebook repl' but in DrRacket interactions,(not a webapp) where the history is visible as a sequence of 'cells' that can be re-evaluated individually. (maybe different cells could be differend #lang's.

[rfindler]

I think alt-arrows are taken (sexpression movement on the mac, and line or maybe word under windows?). I think <menukey>-a should not change (ala the human interface guidelines) but would welcome another keystroke to do that. I'm slightly skeptical of having typing automatically take you back down to the prompt, as it seems confusing. How about having a shortcut key to take you back down instead?

re going further: I think that making an entirely new kind of REPL for DrRacket would be an interesting project with a lot of difficult design and implementation work. I'm all for it, but perhaps not going to help too much personally.

[laszlokorte]

I'm not keen on introducing modes in user interfaces because they make mode errors that are frustrating to users possible. I agree that the modes I suggested should be as transparent to the user as possible (switching between them automatically)

@spdegabrielle your list look fine to me. I would add (but not that important):

• pressing enter when outside the current line copies the current selected s-expression and returns to the current prompt to the position where the prompt-cursor has been before leaving the prompt because that would allow for easier composition of expressions
• pressing alt-a could still select everything if the cursor is outside the prompt but only the prompt if it's inside

I'm slightly skeptical of having typing automatically take you back down to the prompt, as it seems confusing.

@rfindler Currently when typing outside the prompt nothing happens, isn't that confusing?

[rfindler]

re " Currently when typing outside the prompt nothing happens, isn't that confusing?": I suppose. Jumping seems worse to me is all I'm saying.

[spdegabrielle]

Should we just see if we can achieve

!“pressing alt-a could still select everything if the cursor is outside the prompt but only the prompt if it's inside“

A good start and anything more is a bonus.

[rfindler]

A new key binding? That works for me.

On Fri, Jul 5, 2019 at 4:08 PM Stephen De Gabrielle < notifications@github.com> wrote:

Should we just see if we can achieve

!“pressing alt-a could still select everything if the cursor is outside the prompt but only the prompt if it's inside“

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/racket/drracket/issues/283?email_source=notifications&email_token=AADBNMGGDW5DJOH2FTKJXGTP56Z5NA5CNFSM4H57DUV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKKBGA#issuecomment-508862616, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBNMHQUXCJEPVMOIFTBKDP56Z5NANCNFSM4H57DUVQ .