Some keybindings used by PSReadLine aren't getting through

[DJackman123]

Environment

Windows build number: 10.0.18362.86
Windows Terminal version (if applicable): 0.1.1361.0

Any other software?

Steps to reproduce

Open a PowerShell tab in Windows Terminal. Attempt to use these PSReadLine key bindings (use the Get-PSReadLineKeyHandler command to see a list of all key bindings):

• Ctrl+Backspace (BackwardKillWord)
• Shift+Ctrl+Enter (InsertLineBelow)
• Ctrl+Space (MenuComplete)
• Shift+Tab (TabCompletePrevious)
• Alt+0 (DigitArgument) (and other digits)
• PageDown (ScrollDisplayDown)
• Ctrl+PageDown (ScrollDisplayDownLine)
• PageUp (ScrollDisplayUp)
• Ctrl+PageUp (ScrollDisplayUpLine)
• Ctrl+Alt+? (ShowKeyBindings)
• Alt+? (WhatIsKey)

Expected behavior

Key executes the specified PSReadLine function.

Actual behavior

Nothing happens (or the current tab changes in the case of Alt+digit)

[DHowett-MSFT]

This is likely a duplicate of #530 but with more information

[DHowett-MSFT]

TL;DR: There are actually some things that just cannot be represented via VT sequences, (Shift-Ctrl-Enter, Shift-[anything that isn't a letter/number]), and for which we'll need to devise or extend a standard.

[oising]

@DHowett-MSFT -- I was thinking about this before and there is a VT200+ command, DECUDK for user-defined keys. Normally this is limited to fifteen of the terminal's top-row function keys: F6 through F14, Do, Help, and F17 through F20. They are only triggered by using shift: e.g. shift+F6 will emit the user defined sequence, but F6 alone remains F6. What if we extended this scheme to cover Enter, Backspace, Del etc? The devil is in the details but it's somewhat consistent and keeps shift as an independently inert key in VT land. I'm not sure how this might work with respect to shift+ctrl+enter, since we'd be redefining ctrl+enter, not just enter. Unless we choose to read that as shift+enter is an entirely new key, and that ctrl is a modifier for that. Hmmm.

[zadjii-msft]

In my opinion, the right way to fix this is to add support for full INPUT_RECORDs via VT, at least between the Terminal and Conpty. This'll let the terminal act just like conhost in terms of keypresses, but requires a decent amount of work.

The other potential trick here is how do we get full INPUT_RECORDs in UWP? Doesn't seem to me like all the state we'd want is actually exposed, so we might have to live with "good enough" INPUT_RECORD synthesis, and only fill in the info we can gather.

[oising]

@zadjii-msft As long as it doesn't become a nest of windows-specific magic. One of the goals of ConPTY is to allow anyone to write a drop-in replacement terminal that speaks VT. If it has to speak WinAPI then I think we've failed somewhere along the way.

[zadjii-msft]

Oh I'm very aware of that. I think this is primarily a case of making sure that Windows-specific programs running attached to a conpty terminal can still behave the way they used to, if the terminal is capable of acting as a Windows-specific terminal.

The alternative is driving with PSReadline to stop using those keychords, because they won't work on *nix. Kinda curious that this is still a problem at all, with all the cross-platform stuff powershell is working on. I woulda thought they changed those keybindings. I guess them changing the defaults won't prevent people from setting them back to what they like, even if they don't work cross-platform.

[DJackman123]

The problem with pushing it back to PSReadLine to change its default keybindings is that the whole reason these particular bindings were used was to make the text editing experience in PowerShell consistent with other text editors (like Visual Studio). That's the case for keybindings like Ctrl+Backspace, Ctrl+Space, PageUp, and PageDown especially.