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

Cursor up in multi-line mode doesn't move to the previous line #317

Closed
tailhook opened this issue Jan 6, 2020 · 3 comments · Fixed by #324
Closed

Cursor up in multi-line mode doesn't move to the previous line #317

tailhook opened this issue Jan 6, 2020 · 3 comments · Fixed by #324

Comments

@tailhook
Copy link
Contributor

tailhook commented Jan 6, 2020

In most other shells I've used cursor keys work up and down when inside the multi-line string and only switch history on the first and last lines of that input respectively. Is there a configuration that allows that in rustyline?

@gwenn
Copy link
Collaborator

gwenn commented Jan 6, 2020

No.
readline/editline don't:

$ echo test^V^J
test

We need to either fix #293 or fix edit_history_next.

@tailhook
Copy link
Contributor Author

tailhook commented Jan 9, 2020

Well, I couldn't implement this in terms of #293 because of a bug (reported there). But also it's harder than needed because I could only move cursor using BackwardChar/ForwardChar. It would be much nicer if we had one of the two:

  1. VisibleLineUp/Down actions
  2. Move the cursor to "offset"

Also, cursor position measuring is non-trivial, so it might need to be exposed somehow.

I propose to proceed this by adding four built-in actions:

  1. VisibleLineUp/Down
  2. ConditionalUp/Down (or find a better name) to move up or switch history

I don't want to change current Next/PrevHistory actions because I'd like to leave Ctrl-P/Ctrl-N to listing history. And vi-mode j/k to always move over visible line (the latter would be a breaking change though).

Later we can discuss what default bindings for Up/Down should be.

What do you think?

@gwenn
Copy link
Collaborator

gwenn commented Jan 9, 2020

Yes, I know:

We need to either fix #293 [...]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants