Flexible AcceptLine, fix bug in multi-line accept #379
Conversation
src/lib.rs
Outdated
| // Move to end, in case cursor was in the middle of the | ||
| // line, so that next thing application prints goes after | ||
| // the input | ||
| s.edit_move_buffer_end()?; |
There was a problem hiding this comment.
If line is empty, there is no need to move the cursor, no?
There was a problem hiding this comment.
Yes. But we need to clear the hint. Fixed.
* This commit allows keybinding for forcing accept line (even if validator fails). This is useful if you have a separate keybinding for accepting, such as `Alt-Enter`. It makes sense to show an error to user rather than insert an unexpected newline. * Forcing `Newline` is also accepted * `AcceptLine` meaning is changed (not it forces accept), but default `Enter` keybinding is not * `AcceptOrInsertLine` not has a flag that modifies it's behavior in the middle of the line (at the end it always submits, when validator returned false it's always a newline) * Fixed bug with exiting readline (both on success and error) when cursor is not on the last line
src/lib.rs
Outdated
| @@ -281,15 +281,16 @@ fn page_completions<C: Candidate, H: Helper>( | |||
| && cmd != Cmd::SelfInsert(1, ' ') | |||
| && cmd != Cmd::Kill(Movement::BackwardChar(1)) | |||
| && cmd != Cmd::AcceptLine | |||
| && cmd != Cmd::AcceptOrInsertLine | |||
| && cmd != Cmd::Newline | |||
| && matches!(cmd, Cmd::AcceptOrInsertLine { .. }) | |||
There was a problem hiding this comment.
&& !matches!(cmd, Cmd::AcceptOrInsertLine { .. }) (not matches)
src/lib.rs
Outdated
| @@ -509,8 +511,12 @@ fn readline_edit<H: Helper>( | |||
| s.edit_overwrite_char(c)?; | |||
| } | |||
| Cmd::EndOfFile => { | |||
| if s.has_hint() || !s.is_default_prompt() { | |||
There was a problem hiding this comment.
Only if line is empty or in vi mode ?
That is when the action is not edit_delete.
There was a problem hiding this comment.
Fixed. But I'm not sure that if !input_state.is_emacs_mode() && !s.line.is_empty() makes sense. Ctrl+D should be "scroll downwards" in vim, not "submit".
| => { | ||
| break; | ||
| } | ||
| | (Cmd::Newline, _, _) |
There was a problem hiding this comment.
Fixed. Thanks!
(this is actually why I'd like the top-level match to be exhaustive, as this error would have been spotted by the compiler)
src/lib.rs
Outdated
| // Move to end, in case cursor was in the middle of the | ||
| // line, so that next thing application prints goes after | ||
| // the input | ||
| s.edit_move_end()?; |
There was a problem hiding this comment.
Yes, that's better. Thanks!
| @@ -913,7 +929,9 @@ impl InputState { | |||
| } | |||
| } | |||
| KeyPress::Ctrl('J') | | |||
| KeyPress::Enter => Cmd::AcceptLine, | |||
| KeyPress::Enter => { | |||
There was a problem hiding this comment.
AcceptLine == AcceptOrInsertLine { accept_in_the_middle: true } ?
There was a problem hiding this comment.
Yes, accept whatever is fully formed command or insert a newline otherwies. That's for backwards compatibility. As described in the docstring above this is what makes most sense for mostly-single-line cases (i.e. a command-line like in nushell).
|
Thanks you. |
| } | ||
| if s.line.is_empty() { | ||
| return Err(error::ReadlineError::Eof); | ||
| } else if !input_state.is_emacs_mode() { |
validator fails). This is useful if you have a separate keybinding
for accepting, such as
Alt-Enter. It makes sense to show an errorto user rather than insert an unexpected newline.
Newlineis also acceptedAcceptLinemeaning is changed (now it forces accept),but default
Enterkeybinding is notAcceptOrInsertLinenow has a flag that modifies it's behavior inthe middle of the line (at the end it always submits, when validator
returned false it's always a newline)
cursor is not on the last line
I'm not sure that current command-names are the best possible, so let me know if we can do better. The primary motivator was (1) from above.
This conflicts with #342. I'll rebase other one when either of them is merged.