Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
3 tasks done
kgryte opened this issue Mar 26, 2024 · 8 comments · May be fixed by #2347
Open
3 tasks done

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

kgryte opened this issue Mar 26, 2024 · 8 comments · May be fixed by #2347
Labels
difficulty: 3 Likely to be challenging but manageable. Enhancement Issue or pull request for enhancing existing functionality. JavaScript Issue involves or relates to JavaScript. Needs Discussion Needs further discussion. priority: Normal Normal priority concern or feature request. REPL Issue or pull request specific to the project REPL. RFC Request for comments. Feature requests and proposed changes.

Comments

@kgryte
Copy link
Member

kgryte commented Mar 26, 2024

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:.
@kgryte kgryte added Enhancement Issue or pull request for enhancing existing functionality. RFC Request for comments. Feature requests and proposed changes. Needs Discussion Needs further discussion. difficulty: 3 Likely to be challenging but manageable. REPL Issue or pull request specific to the project REPL. priority: Normal Normal priority concern or feature request. JavaScript Issue involves or relates to JavaScript. labels Mar 26, 2024
@kgryte
Copy link
Member Author

kgryte commented Mar 27, 2024

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.

@Snehil-Shah
Copy link
Contributor

Snehil-Shah commented Mar 27, 2024

@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?

@kgryte
Copy link
Member Author

kgryte commented Mar 27, 2024

@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. 😅

@kgryte
Copy link
Member Author

kgryte commented Mar 27, 2024

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.

@Snehil-Shah
Copy link
Contributor

@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.

@kgryte
Copy link
Member Author

kgryte commented Mar 27, 2024

Agreed.

kgryte added a commit to Snehil-Shah/stdlib that referenced this issue Mar 28, 2024
Modifiers were generally not recognized on my Macbook Pro. In general,
we should rethink multi-line editing and, once we do some more R&D,
add support in a follow-up PR.

Ref: stdlib-js#2060
@kgryte
Copy link
Member Author

kgryte commented Apr 22, 2024

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.

@Snehil-Shah
Copy link
Contributor

@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.

@Snehil-Shah Snehil-Shah linked a pull request Jun 9, 2024 that will close this issue
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty: 3 Likely to be challenging but manageable. Enhancement Issue or pull request for enhancing existing functionality. JavaScript Issue involves or relates to JavaScript. Needs Discussion Needs further discussion. priority: Normal Normal priority concern or feature request. REPL Issue or pull request specific to the project REPL. RFC Request for comments. Feature requests and proposed changes.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants