Some keybindings used by PSReadLine aren&#39;t getting through #1192

@oising commented on GitHub (May 19, 2019):

@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.

@oising commented on GitHub (May 19, 2019): @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.

claunia commented

@zadjii-msft commented on GitHub (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.

@zadjii-msft commented on GitHub (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.

claunia commented

@DJackman123 commented on GitHub (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.

@DJackman123 commented on GitHub (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.

claunia commented

@lzybkr commented on GitHub (May 31, 2019):

Alacritty has an interesting solution to this problem. They support remapping keys (from the OS point of view) to arbitrary character (VT) sequences. See their default config file.

This would still require custom key bindings in PSReadLine or similar applications. For example, in my alacritty.yml, I might add:

  # Replace Ctrl+Space with F12,a
  - { key: Space,    mods: Control,   chars: "\x1b[24~a"                     }

Then in my PowerShell profile I might add:

Set-PSReadLineKeyHandler -Chord 'F12,a' -Function MenuComplete

@lzybkr commented on GitHub (May 31, 2019): Alacritty has an interesting solution to this problem. They support remapping keys (from the OS point of view) to arbitrary character (VT) sequences. See their default [config file](https://github.com/jwilm/alacritty/blob/dea7a0890a724c50bc5767039f45a2e3d071ee1c/alacritty.yml#L533). This would still require custom key bindings in PSReadLine or similar applications. For example, in my `alacritty.yml`, I might add: ``` # Replace Ctrl+Space with F12,a - { key: Space, mods: Control, chars: "\x1b[24~a" } ``` Then in my PowerShell profile I might add: ```powershell Set-PSReadLineKeyHandler -Chord 'F12,a' -Function MenuComplete ```

claunia commented

@oising commented on GitHub (Jun 11, 2019):

It turns out that the xterm guys may have a more generalized approach for dealing with modifiers:

CSI > Ps ; Ps m
          Set or reset resource-values used by xterm to decide whether
          to construct escape sequences holding information about the
          modifiers pressed with a given key.

          The first parameter identifies the resource to set/reset.  The
          second parameter is the value to assign to the resource.

          If the second parameter is omitted, the resource is reset to
          its initial value.

            Ps = 0  -> modifyKeyboard.
            Ps = 1  -> modifyCursorKeys.
            Ps = 2  -> modifyFunctionKeys.
            Ps = 4  -> modifyOtherKeys.

          If no parameters are given, all resources are reset to their
          initial values.

I know we're trying not to step too far outside DEC VT stuff, but xterm is the de-facto standard. I don't think we should aim to emulate xterm, but we definitely need to take on enough to solve our open problems. Anyway, this seems to imply that xterm has a scheme for passing modifiers for all keys, not just shifted f5-f20 on vanilla DEC hardware.

Thoughts?

@oising commented on GitHub (Jun 11, 2019): It turns out that the xterm guys may have a more generalized approach for dealing with modifiers: ``` CSI > Ps ; Ps m Set or reset resource-values used by xterm to decide whether to construct escape sequences holding information about the modifiers pressed with a given key. The first parameter identifies the resource to set/reset. The second parameter is the value to assign to the resource. If the second parameter is omitted, the resource is reset to its initial value. Ps = 0 -> modifyKeyboard. Ps = 1 -> modifyCursorKeys. Ps = 2 -> modifyFunctionKeys. Ps = 4 -> modifyOtherKeys. If no parameters are given, all resources are reset to their initial values. ``` I know we're trying not to step too far outside DEC VT stuff, but xterm is the de-facto standard. I don't think we should aim to emulate xterm, but we definitely need to take on enough to solve our open problems. Anyway, this seems to imply that xterm has a scheme for passing modifiers for all keys, not just shifted f5-f20 on vanilla DEC hardware. Thoughts?

claunia commented

@zadjii-msft commented on GitHub (Jun 12, 2019):

Oh, that's a really good idea. We'd need to add support to conpty for parsing them, but that shouldn't be impossible.

@zadjii-msft commented on GitHub (Jun 12, 2019): Oh, that's a _really good idea_. We'd need to add support to conpty for parsing them, but that shouldn't be impossible.

claunia commented

@oising commented on GitHub (Jun 12, 2019):

Just to add more to the mix, here's Kitty's approach: https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling

The escape sequence encodes the following properties:
Type of event: press,repeat,release
Modifiers pressed at the time of the event
The actual key being pressed

As you can see, they've got a pretty good analog of how we already encode things with INPUT_RECORD. I'm curious if xterm does the same.

@oising commented on GitHub (Jun 12, 2019): Just to add more to the mix, here's Kitty's approach: https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling > The escape sequence encodes the following properties: > Type of event: press,repeat,release > Modifiers pressed at the time of the event > The actual key being pressed As you can see, they've got a pretty good analog of how we already encode things with INPUT_RECORD. I'm curious if xterm does the same.

claunia commented

@miniksa commented on GitHub (Jun 24, 2019):

I generally prefer the xterm way. xterm is the de facto standard for terminal communication. Generally any valid VT parser should discard those particular CSIs if they don't understand them. And if we can get away with solving the problem without going fully toward the INPUT_RECORD model, then I think we should.

However, Kitty's approach does seem pretty decent if we do indeed end up having to do something like INPUT_RECORD. There looks to be a provision to reset out of the special mode... but I would say that not a ton of applications/terminals/users are expecting or ready to do a reset when things go wrong. And if a reset doesn't occur... we could be causing strange things to happen.

I think this won't become clear until we choose a path and start down it by trying it out. At which point, I'd encourage the xterm-style way first until proven otherwise.

If anything, I think we should probably accept both methods as input to our system but only actively try to emit the xterm way out of the pty interface until proven otherwise.

@miniksa commented on GitHub (Jun 24, 2019): I generally prefer the xterm way. xterm is the de facto standard for terminal communication. Generally any valid VT parser should discard those particular CSIs if they don't understand them. And if we can get away with solving the problem without going fully toward the `INPUT_RECORD` model, then I think we should. However, Kitty's approach does seem pretty decent if we do indeed end up having to do something like `INPUT_RECORD`. There looks to be a provision to reset out of the special mode... but I would say that not a ton of applications/terminals/users are expecting or ready to do a reset when things go wrong. And if a reset doesn't occur... we could be causing strange things to happen. I think this won't become clear until we choose a path and start down it by trying it out. At which point, I'd encourage the xterm-style way first until proven otherwise. If anything, I think we should probably accept both methods as input to our system but only actively try to emit the xterm way out of the pty interface until proven otherwise.

claunia commented

2026-01-30 22:18:42 +00:00

@oising commented on GitHub (Jun 24, 2019):

Agree @miniksa -- the Kitty guy's protocol using Application Program Commands (APC) is pretty neat, but it's de-facto making anything that parses them a "KittyApp"(tm) and not a VT app. I guess Xterm are doing the same thing, but they are the Gold Standard. APC is meant for VT apps to signal each other, and should be ignored (never echoed) by terminals (although DEC does use some APCs itself, namely DECEKBD -- extended keyboard report.) That said, it's a open, well-known way to do internal signalling, if needed.

@oising commented on GitHub (Jun 24, 2019): Agree @miniksa -- the Kitty guy's protocol using Application Program Commands (APC) is pretty neat, but it's de-facto making anything that parses them a "KittyApp"(tm) and not a VT app. I guess Xterm are doing the same thing, but they are the Gold Standard. APC is meant for VT apps to signal each other, and should be ignored (never echoed) by terminals (although DEC does use some APCs itself, namely DECEKBD -- extended keyboard report.) That said, it's a open, well-known way to do internal signalling, if needed.

claunia commented

@ocalvo commented on GitHub (Jul 2, 2019):

Just want to point out that legacy tools like ZtreeWin are very hard to impossible to use under Windows Terminal without some kind of support for direct raw input.

@ocalvo commented on GitHub (Jul 2, 2019): Just want to point out that legacy tools like [ZtreeWin](http://www.ztree.com/html/ztreewin.htm) are very hard to impossible to use under Windows Terminal without some kind of support for direct raw input.

claunia commented

2026-01-30 22:18:42 +00:00

@DHowett-MSFT commented on GitHub (Jul 2, 2019):

Here's a thought: could this instead just be a profile setting? "I want to run a legacy thing like ZTW" => "do the raw input dance"

@DHowett-MSFT commented on GitHub (Jul 2, 2019): Here's a thought: could this instead just be a profile setting? "I want to run a legacy thing like ZTW" => "do the raw input dance"

claunia commented

2026-01-30 22:18:42 +00:00

@Tyriar commented on GitHub (Aug 2, 2019):

Just throwing my vote in for the xterm way. xterm.js doesn't implement CSI > Ps ; Ps m yet, but if it helps solve this issue we definitely would.

@Tyriar commented on GitHub (Aug 2, 2019): Just throwing my vote in for the xterm way. xterm.js doesn't implement `CSI > Ps ; Ps m` yet, but if it helps solve this issue we definitely would.

claunia commented

2026-01-30 22:18:43 +00:00

@j4james commented on GitHub (Nov 12, 2019):

Another option to consider would be the VT510 PCTerm mode (enabled with DECPCTERM), where the keyboard generates a unique scancode (typically one byte) for both the press and release of every key. With that you should be able to handle any key combination imaginable.

You can see a list of the scan codes here:
https://vt100.net/docs/vt510-rm/chapter8.html#S8.13

@j4james commented on GitHub (Nov 12, 2019): Another option to consider would be the VT510 _PCTerm_ mode (enabled with [DECPCTERM](https://vt100.net/docs/vt510-rm/DECPCTERM.html)), where the keyboard generates a unique scancode (typically one byte) for both the press and release of every key. With that you should be able to handle any key combination imaginable. You can see a list of the scan codes here: https://vt100.net/docs/vt510-rm/chapter8.html#S8.13

claunia commented

2026-01-30 22:18:43 +00:00

@oising commented on GitHub (Nov 12, 2019):

Another option to consider would be the VT510 PCTerm mode (enabled with DECPCTERM), where the keyboard generates a unique scancode (typically one byte) for both the press and release of every key. With that you should be able to handle any key combination imaginable.

You can see a list of the scan codes here:
https://vt100.net/docs/vt510-rm/chapter8.html#S8.13

Man, DEC really were the masters of having twenty different ways to do something. I hadn't seen this before. Very interesting.

@oising commented on GitHub (Nov 12, 2019): > Another option to consider would be the VT510 _PCTerm_ mode (enabled with [DECPCTERM](https://vt100.net/docs/vt510-rm/DECPCTERM.html)), where the keyboard generates a unique scancode (typically one byte) for both the press and release of every key. With that you should be able to handle any key combination imaginable. > > You can see a list of the scan codes here: > https://vt100.net/docs/vt510-rm/chapter8.html#S8.13 Man, DEC really were the masters of having twenty different ways to do something. I hadn't seen this before. Very interesting.

claunia commented

@factormystic commented on GitHub (Jan 22, 2020):

Just curious, how come this works okay in conhost? Is it because that is working with raw input, whereas terminal is only processing characters?

@factormystic commented on GitHub (Jan 22, 2020): Just curious, how come this works okay in conhost? Is it because that is working with raw input, whereas terminal is only processing characters?

claunia commented

@zadjii-msft commented on GitHub (Jan 22, 2020):

@factormystic basically, yes. The full story's much more complicated, but that's definitely the tl;dr version.

For my future sanity, the text on invisible-island changed:

CSI > Pp ; Pv m
CSI > Pp m
          Set/reset key modifier options, xterm.  Set or reset resource-
          values used by xterm to decide whether to construct escape
          sequences holding information about the modifiers pressed with
          a given key.

          The first parameter Pp identifies the resource to set/reset.
          The second parameter Pv is the value to assign to the
          resource.

          If the second parameter is omitted, the resource is reset to
          its initial value.  Values 3  and 5  are reserved for keypad-
          keys and string-keys.

            Pp = 0  ⇒  modifyKeyboard.
            Pp = 1  ⇒  modifyCursorKeys.
            Pp = 2  ⇒  modifyFunctionKeys.
            Pp = 4  ⇒  modifyOtherKeys.

          If no parameters are given, all resources are reset to their
          initial values.

Also:

It seems to work in xterm, but maybe not gnome-terminal

\x1[<something maybe>;<modifiers>;<char value>~

for <char value>: space == 32, A=65, a=97, etc

@zadjii-msft commented on GitHub (Jan 22, 2020): @factormystic basically, yes. The full story's much more complicated, but that's definitely the tl;dr version. <hr> For my future sanity, the text on invisible-island changed: ``` CSI > Pp ; Pv m CSI > Pp m Set/reset key modifier options, xterm. Set or reset resource- values used by xterm to decide whether to construct escape sequences holding information about the modifiers pressed with a given key. The first parameter Pp identifies the resource to set/reset. The second parameter Pv is the value to assign to the resource. If the second parameter is omitted, the resource is reset to its initial value. Values 3 and 5 are reserved for keypad- keys and string-keys. Pp = 0 ⇒ modifyKeyboard. Pp = 1 ⇒ modifyCursorKeys. Pp = 2 ⇒ modifyFunctionKeys. Pp = 4 ⇒ modifyOtherKeys. If no parameters are given, all resources are reset to their initial values. ``` Also: * https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:modifyOtherKeys * https://invisible-island.net/xterm/modified-keys.html It seems to work in `xterm`, but maybe not `gnome-terminal` ![image](https://user-images.githubusercontent.com/18356694/72923205-34a39f00-3d14-11ea-98af-4300f0ee64ad.png) `\x1[<something maybe>;<modifiers>;<char value>~` for `<char value>`: `space` == `32`, `A`=`65`, `a`=`97`, etc

claunia commented

@natebarkei commented on GitHub (Jan 23, 2020):

This seriously breaks the usability of terminal for powershell. I realize what I'm saying here doesn't really add to the solution. But even though this is a difficult problem, I feel that by not assigning this a higher priority for fixing, it shows a lack of concern for a basic mandatory feature of this program.

Please bump this higher in your stack of things to fix/solve!!

@natebarkei commented on GitHub (Jan 23, 2020): This seriously breaks the usability of terminal for powershell. I realize what I'm saying here doesn't really add to the solution. But even though this is a difficult problem, I feel that by not assigning this a higher priority for fixing, it shows a lack of concern for a basic **mandatory** feature of this program. Please bump this higher in your stack of things to fix/solve!!

claunia commented

@koron commented on GitHub (Feb 1, 2020):

#3935 modified (fixed?) for Ctrl+Backspace only.
But it breaks Ctrl+h behavior for many applications.

@koron commented on GitHub (Feb 1, 2020): #3935 modified (fixed?) for <kbd>Ctrl+Backspace</kbd> only. But it breaks <kbd>Ctrl+h</kbd> behavior for many applications.

claunia commented

@TunerBuilder commented on GitHub (Mar 12, 2020):

Do we have any updates about this?
I was really thrilled at the beginning about the project, but if basic functionalities such as CTRL + SPACE do not work, I don't see the point of using it.

@TunerBuilder commented on GitHub (Mar 12, 2020): Do we have any updates about this? I was really thrilled at the beginning about the project, but if basic functionalities such as CTRL + SPACE do not work, I don't see the point of using it.

claunia commented

@zadjii-msft commented on GitHub (Mar 12, 2020):

When there are updates, we'll be sure to post here. We agree that this is a highly important feature, but it's one that unfortunately is going to take a lot of work to get quite right. It's a harder problem than just "add this keychord to the terminal" - it involves implementing an entire other input encoding to the conpty backend, and then also implementing a similar synthesis of input from the Terminal.

I've got this crazy thought that some of the work in #4856 might enable this keybinding for WSL applications, but it still won't work for Win32 console apps, like powershell.exe and pwsh.exe.

@zadjii-msft commented on GitHub (Mar 12, 2020): When there are updates, we'll be sure to post here. We agree that this is a highly important feature, but it's one that unfortunately is going to take a lot of work to get quite right. It's a harder problem than just "add this keychord to the terminal" - it involves implementing an entire other input encoding to the conpty backend, and then also implementing a similar synthesis of input from the Terminal. I've got this crazy thought that some of the work in #4856 might enable this keybinding for WSL applications, but it still won't work for Win32 console apps, like `powershell.exe` and `pwsh.exe`.

claunia commented

@lzybkr commented on GitHub (Mar 12, 2020):

@zadjii-msft - PSReadLine supports VT input mode if you set $env:PSREADLINE_VTINPUT = 1. As it isn't the default, it's not widely tested. It could in fact be completely broken, but the person who implemented it was happy with using that mode under tmux.

@lzybkr commented on GitHub (Mar 12, 2020): @zadjii-msft - PSReadLine supports VT input mode if you set `$env:PSREADLINE_VTINPUT = 1`. As it isn't the default, it's not widely tested. It could in fact be completely broken, but the person who implemented it was happy with using that mode under `tmux`.

claunia commented

@zadjii-msft commented on GitHub (Mar 12, 2020):

@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 = 1 set.

@zadjii-msft commented on GitHub (Mar 12, 2020): @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 <kbd>Ctrl+Space</kbd>, 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 = 1` set.

claunia commented

@lzybkr commented on GitHub (Mar 12, 2020):

It's probably an easy fix here.

@lzybkr commented on GitHub (Mar 12, 2020): It's probably an easy fix [here](https://github.com/PowerShell/PSReadLine/blob/198a64390e713214df20ef580f7a546b5c3ac1e8/PSReadLine/CharMap.cs#L221).

claunia commented

@yanoryuichi commented on GitHub (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.

@yanoryuichi commented on GitHub (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.

claunia commented

@awson commented on GitHub (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)

@awson commented on GitHub (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)

claunia commented