Unable to do Meta-Left or Meta-Right

[mgattozzi]

The current implementation of KeyPress only allows Meta to take a char rather than another KeyPress, which also has a KeyPress::Char(char) variant, and as such it disallows multi char control sequences. On OSX if one wishes to implement Ctrl+Left or Ctrl+Right functionality for a terminal shell the equivalent is Meta+Left and Meta+Right as the prior functionality is bound to switching workspaces.

Would having it take a KeyPress be reasonable? I see that things like KeyPress::ControlLeft exist but this seems less flexible rather than allowing some command modifier taking another KeyPress or multiple of them. Maybe I'm missing some architectural choice as to why it is this way, but I couldn't find anything in the issues or git log that would help me figure out why and have probably overlooked something here.

[gwenn]

I guess it is for historical reason: see linenoise keys
Also see #121.
And python-prompt-toolkit special keys

On macOs (iterm2), typing meta-letf (Esc + Left) gives:

$ [D

On Archlinux VM, typing meta-left moves to the start of word.

[gwenn]

Just for reference:

• termion/liner
• mortal/linefeed
• crossterm
• termwiz

[sophiajt]

I think meta-left/meta-right works in macOS for linefeed.

[gwenn]

Alt+Leftworks in macOS for linefeed (and rustyline).
But not Esc+Left: the combination is interpreted as a single Left by linefeed.

[gwenn]

By default, both Terminal.app and iTerm2.app are configured to sent Esc-b when Alt+Left are pressed...

[thomcc]

Hmm, my iTerm does \e\e[D/\e\e[C for alt+l/r. Still annoyingly non-standard, but not as bad. This follows what's listed in https://invisible-island.net/ncurses/terminfo.src.html for iTerm2.app (Surprised there's even an entry there -- iTerm sets its TERM variable to xterm-256color)

That said, Terminal.app does behave as you describe for me (\ef/\eb). Anyway that PR fixes this for me, I still need to make sure it doesn't break anything, I don't think escape parsing was covered by tests?

[gwenn]

From a Windows perspective, it makes sense to separate key code and modifiers.
But from a Unix perspective, we would not be able to report a Ctrl-Alt-Shift-M...

[thomcc]

Not entirely true, see: https://github.com/kkawakam/rustyline/pull/333/files#diff-0655ced7de6892bafa1f0000619c718eR327-R330 (and linked page).

In practice I think terms tend to only send meta or alt though, and so that code just treats any Meta/Alt presses it gets the same. I think you're right for non-special keys though.

(I think this issue is about neither working on macos though -- since it really just has option anyway)

[gwenn]

Version 7.0.0 released