Support Partial Completion

[schrieveslaach]

This commit adds the ability to complete the current line with the word of the hint. When the cursor is at the end of the current line and CTRL + right arrow has been pressed, the next word of the hint will be added to the editor's line.

Closes #413

[gwenn]

You should be able to almost do it by yourself with rustyline >= 8 without hardcoding a nth binding in rustyline.
Except maybe this limitation:

                Some(Cmd::CompleteHint) // TODO give access to hint

[schrieveslaach]

@gwenn, do you suggest that I should extend ConditionalEventHandler or one of the parameters of handle in a way so that a custom handler access the hint to return Some(Cmd::Insert(…, …))?

[schrieveslaach]

I found a solution that fixes the open TODO with a minimal extension of the public API. Please, have another look.

[gwenn]

Perfect !

[schrieveslaach]

@gwenn, do you see any chance to merge this PR?

[schrieveslaach]

Thanks for merging. 👍 😎

[sophiajt]

@gwenn - do you know when the next rustyline will get released? We'd like to be able to use this functionality in Nushell, when it's available

[gwenn]

@jonathandturner 8.1.0 is ready (but not published yet). Could you please confirm that you don't have any building issue on windows related to this change ?

[sophiajt]

@gwenn - it's working for me in Windows

[gwenn]

@jonathandturner Version 8.1.0 released

[sophiajt]

@gwenn great, thanks!

[fdncred]

@gwenn Do you, or anyone else listening, have the ability to test this in MacOS? I have a mac and cannot get it to work. I originally thought that MacOS was eating the commands ctrl+right and ctrl+left because when I use those keystrokes it changes to the next virutal desktop. So, I disabled those keystrokes in the MacOS preferences. But when I tried again, it still didn't work. I'm just wondering if anyone else has this experience and what they did to fix it?

I also tried cmd+right/left and option+right/left to no avail.

[ryanpcmcquen]

Yeah, I am really excited for this but can't seem to get it working on Mac OS. Option + left/right would be ideal (that is what Fish uses).

[gwenn]

@fdncred You can trace key events (or unsupported ANSI escape sequences) easily by using RUST_LOG=rustyline=debug cargo run --example example 2> debug.log. Currently, on MacOS (BigSur), there is no event with iTerm or Terminal.
See https://superuser.com/questions/205470/why-is-ctrl-arrow-not-working-in-bash-on-os-x.
Maybe we should try and see if crossterm or termwiz or ... manages to catch these keys.

[gwenn]

crossterm % cargo run --example event-read => no event
termwiz % cargo run --example key_tester => no event
For iTerm, Cmd+Left / Right are used to switch between tabs.

[fdncred]

@fdncred You can trace key events (or unsupported ANSI escape sequences) easily by using RUST_LOG=rustyline=debug cargo run --example example 2> debug.log. Currently, on MacOS (BigSur), there is no event with iTerm or Terminal.
See https://superuser.com/questions/205470/why-is-ctrl-arrow-not-working-in-bash-on-os-x.
Maybe we should try and see if crossterm or termwiz or ... manages to catch these keys.

This is what I get using the command you specified. It launched and I did:
control+left
control+right
alt/option+left
alt/option+right
command+left
command+right
ctrl+c

It doesn't look like all my keystrokes were captured.

[DEBUG rustyline::history] PathInfo("history.txt", SystemTime { tv_sec: 1621454572, tv_nsec: 410962579 }, 1)
[DEBUG rustyline::edit] old layout: Layout { prompt_size: Position { col: 0, row: 0 }, default_prompt: false, cursor: Position { col: 0, row: 0 }, end: Position { col: 0, row: 0 } }
[DEBUG rustyline::edit] new layout: Layout { prompt_size: Position { col: 3, row: 0 }, default_prompt: true, cursor: Position { col: 3, row: 0 }, end: Position { col: 3, row: 0 } }
[DEBUG rustyline::tty::unix] key: KeyEvent(Left, ALT)
[DEBUG rustyline::keymap] Emacs command: Move(BackwardWord(1, Emacs))
[DEBUG rustyline::tty::unix] key: KeyEvent(Right, ALT)
[DEBUG rustyline::keymap] Emacs command: Move(ForwardWord(1, AfterEnd, Emacs))
[DEBUG rustyline::tty::unix] key: KeyEvent(Left, NONE)
[DEBUG rustyline::keymap] Emacs command: Move(BackwardChar(1))
[DEBUG rustyline::tty::unix] key: KeyEvent(Right, NONE)
[DEBUG rustyline::keymap] Emacs command: Move(ForwardChar(1))
[DEBUG rustyline::tty::unix] key: KeyEvent(Char('C'), CTRL)
[DEBUG rustyline::keymap] Emacs command: Interrupt

I also have this in my ~/.inputrc just trying out the different options.

"\e[5C": forward-word
"\e[5D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word

[gwenn]

@fdncred If you see no KeyEvent (even UnknownEscSeq), it means that nothing is read from stdin.

[fdncred]

I guess that's what's happening because there are no debug logs for control+right and control+left. So, is the theory that MacOS is eating those keystrokes or is it iTerm2?

[ryanpcmcquen]

Any workarounds on MacOS yet?

[gwenn]

For MacOS and ctrl-left / ctrl-right, see https://superuser.com/a/357394:

System Preferences → Keyboard → Shortcuts → Mission Control