Support for win32-input-mode

[nico-abram]

As mentioned in #318 (comment) VT sequences cannot send everything that windows console programs expect (Encoded as win32 INPUT_RECORD's). That issue is about a very specific issue, so I'm opening this one to track support for the propietary win32-input-mode as described in https://github.com/microsoft/terminal/blob/main/doc/specs/%234999%20-%20Improved%20keyboard%20handling%20in%20Conpty.md

However, conpty's keyboard input is fundamentally backed by VT sequences, which limits the range of keys that a terminal application can actually send relative to what the console was capable of. This results in a number of keys that were previously representable in the console as INPUT_RECORDs, but are impossible to send to a client application that's running in conpty mode.

Like wez mentioned in this comment xtermjs/xterm.js#2357 may have some useful comments.

The specific issue I'm having that makes me interested in this is the "Modifier keys are not properly propagated to applications on windows" (documented well for WT here, and more specifically with far manager as mentioned here) listed in the document, but I imagine eventually users with all the problems mentioned in the abstract will show up.

Here are the alternatives I can think of:

• Refuse to implement the mode and don't fully support win32 applications that make use of things not representable as VT

[wez]

This is now implemented in the nightly, with restrictions: only for ambiguous or modifier only keys, which are the ones where this makes the most sense anyway.

[nico-abram]

I can confirm holding modifier keys seems to work fine on nigthtly

[wez]

@DHowett: first bug report about this is: with W32IM enabled in a cmd or pwsh, CTRL+key works correctly. If that session then runs wsl.exe the CTRL modifier is lost, so CTRL-C just sends C, CTRL-L is just L and so on.

This is what wezterm is sending in; the Encoded input as lines are what we write through to conpty:

key_event RawKeyEvent { key: Physical(C), modifiers: CTRL, phys_code: Some(C), raw_code: 67, scan_code: 46, repeat_count: 1, key_is_down: true, handled: Handled(false) }
key_event KeyEvent { key: Char('c'), modifiers: CTRL, repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Physical(C), modifiers: CTRL, phys_code: Some(C), raw_code: 67, scan_code: 46, repeat_count: 1, key_is_down: true, handled: Handled(false) }) }
send to pane key=Char('c') mods=CTRL
Encoded input as "\u{1b}[67;46;99;1;8;1_"
key_event RawKeyEvent { key: Physical(C), modifiers: CTRL, phys_code: Some(C), raw_code: 67, scan_code: 46, repeat_count: 1, key_is_down: false, handled: Handled(false) }
key_event KeyEvent { key: Char('c'), modifiers: CTRL, repeat_count: 1, key_is_down: false, raw: Some(RawKeyEvent { key: Physical(C), modifiers: CTRL, phys_code: Some(C), raw_code: 67, scan_code: 46, repeat_count: 1, key_is_down: false, handled: Handled(false) }) }
send to pane key=Char('c') mods=CTRL
Encoded input as "\u{1b}[67;46;99;0;8;1_"

[wez]

@nico-abram heads up: I turned off allow_win32_input_mode by default until we can figure out what's happening with wsl. You can set allow_win32_input_mode=true in your config to get back your FAR manager modifiers :)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.