Some keybindings used by PSReadLine aren't getting through #879
Description
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)
Reacted by Maximilian Orsley, atwok, Leon V, Chris Simmons, SuperFlue, geogboe, Morten Gjesing, Dennis Duda, SpitFire-666, Jonas and 20 more
Metadata
Metadata
Assignees
Labels
Related to input processing (key presses, mouse, etc.)Virtual Terminal sequence supportIt either shouldn't be doing this or needs an investigation.Complex enough to require an in depth planning process and actual budgeted, scheduled work.Bugs that we consider release-blocking/recall-class (P0)The new Windows Terminal.Fix is checked in, but it might be 3-4 weeks until a release.
Activity
DHowett-MSFT commentedon May 17, 2019
This is likely a duplicate of #530 but with more information
DHowett-MSFT commentedon May 17, 2019
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 commentedon May 17, 2019
Dustin L. Howett (MSFT) (@DHowett-MSFT) -- I was thinking about this before and there is a VT200+ command,
DECUDKfor 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 commentedon May 17, 2019
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_RECORDsynthesis, and only fill in the info we can gather.oising commentedon May 19, 2019
Mike Griese (@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 commentedon May 20, 2019
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 commentedon May 20, 2019
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.
28 remaining items
zadjii-msft commentedon Mar 12, 2020
Jason Shirk (@lzybkr) Oh I didn't know that existed! That's certainly an interesting idea. Looks like with #4856 merged, we do pipe a NUL all the way through conpty to the client app for Ctrl+Space, but PSReadline doesn't accept it as the key for Ctrl+Space. It looks like it's being treated by PsReadline as Ctrl+@. That's perfectly understandable - they both have the same encoding in VT. Weirdly enough though, binding Ctrl-@ to MenuComplete still doesn't trigger it, event with #4856 merged and
PSREADLINE_VTINPUT = 1set.lzybkr commentedon Mar 12, 2020
It's probably an easy fix here.
yanoryuichi commentedon Mar 14, 2020
Not sure it's already fixed in development, but CTRL-H doesn't work in Vim in my environment. It works in Command prompt, but not work in Windows Terminal when I use Vim.
awson commentedon Apr 24, 2020
When I use Far Manager under the Terminal, RightCtrl+N (N is numeric key) keys don't work.
Is it a manifestation of this issue? (if yes, it's very sad, since makes Terminal unusable to host Far Manager)
DHowett-MSFT commentedon Apr 24, 2020
Unfortunately, yes. Anything that requires modifiers alone or specific modifiers (right versus left) is covered by this issue.
Add support for win32-input-mode to conhost, ConPTY, Terminal (#6309)
Update Fork (#1)