stdlib-js/stdlib

[RFC]: add support for multi-line editing to the REPL

kgryte opened this issue · 8 comments

Description

This RFC proposes adding support for multi-line editing to the REPL. Currently, we a user does

In [29]: function foo() {
    // ...
}<|>

where <|> represents the cursor, hitting the up arrow auto-completes previous commands, rather than allows a user to move the cursor up to edit existing content.

It would be nice to allow users to support multi-line editing, as otherwise they need to hit ENTER and start over.

Related Issues

No.

Questions

  • What are the pitfalls and considerations for implementing this? For one, could be tricky to implement due to needing to listen for certain keypress sequences and having to manipulate cursor position via ANSI escape sequences.
  • Should the default be to move the cursor up? Or is there a use case for hitting the up arrow in multi-line mode and auto-completing previous commands?

Other

No.

Checklist

  • I have read and understood the Code of Conduct.
  • Searched for existing issues and pull requests.
  • The issue name begins with RFC:.

Another option for this, which may be better, is to enter an "editor" mode. This would be similar to the built-in Node.js REPL which supports the .editor command.

@kgryte I tried the .editor mode in node, but I can't seem to move up to the previous line using backspaces or the up arrow.
But by editor mode are you proposing a vi editor like experience?

@Snehil-Shah Oh! Interesting. You're right about .editor. You can do multi-line input without triggering execution, but you cannot return to previous lines.

Yes, I suppose I had in mind something more like nano. vi may be a bit much to replicate. 😅

However, with nano, you clear the terminal and input text. It would be nice for multi-line editing to not leave the REPL view (similar to now). But I can see advantages of both approaches: nano vs if the current quasi-multi-line editing could support editing previous lines.

@kgryte I think having both would be great, a nano type editing mode can allow for writing long scripts and programs with maybe even options to export it to a .js file or execute it independently to the rest of the REPL context (like a playground of sorts), while our current multiline (with ability to edit previous lines) can allow for writing normal multiline commands.

Agreed.

Following up on this issue, with the addition of auto-pairing closing symbols, the current approach for multi-line editing (relying on incomplete expressions) no longer works very well and makes for a frustrating UX. Recently, I ended up turning off autoClosePairs, entering function contents to allow "incomplete expression" multi-line editing to work, and re-enabling.

@kgryte We need a keybinding to make multiline editing easier. Yes ALT+ENTER didn't work the last time we tried, but I assume different terminals might be interpreting it differently because of ENTER. We can try a combination like CTRL+O (like IPython) to enter multiline editing and it should work.