Incorrect keycode for &#34;CTRL+H&#34; in Windows Terminal #8212

@DHowett commented on GitHub (May 19, 2020):

So, yes. We placed the Windows encoding for Ctrl+H on the sacrificial altar when we fixed Ctrl+Backspace. We've got plans in the works that'll make this better.

Thanks.

@DHowett commented on GitHub (May 19, 2020): So, yes. We placed the Windows encoding for <kbd>Ctrl+H</kbd> on the sacrificial altar when we fixed <kbd>Ctrl+Backspace</kbd>. We've got plans in the works that'll make this better. Thanks.

claunia commented

@DHowett commented on GitHub (May 19, 2020):

For reference, this will be part of #4999.

@DHowett commented on GitHub (May 19, 2020): For reference, this will be part of #4999.

claunia commented

@skywind3000 commented on GitHub (May 19, 2020):

In the xterm standard:

CTRL+H is 0x08.
BackSpace is 0x1f.
CTRL+BackSpace is 0x1f.

They won't conflict with each other.

@skywind3000 commented on GitHub (May 19, 2020): In the xterm standard: - CTRL+H is `0x08`. - BackSpace is `0x1f`. - CTRL+BackSpace is `0x1f`. ![图片](https://user-images.githubusercontent.com/3035071/82293867-cfb93680-99df-11ea-93d0-b1e48597e64c.png) They won't conflict with each other.

claunia commented

@DHowett commented on GitHub (May 19, 2020):

?

I just used xterm 351 and pressed Backspace, Ctrl+H and Ctrl+Backspace.

They have the same encoding.

@DHowett commented on GitHub (May 19, 2020): ? I just used xterm 351 and pressed <kbd>Backspace</kbd>, <kbd>Ctrl+H</kbd> and <kbd>Ctrl+Backspace</kbd>. ![image](https://user-images.githubusercontent.com/189190/82294684-6267c000-9963-11ea-95aa-3093c9a3dd4f.png) They have the same encoding.

claunia commented

@skywind3000 commented on GitHub (May 19, 2020):

@DHowett

Thanks for including this in milestone 1.1,

@tasogare3710 ,

Vim doesn't require PDCurses, it uses Win32 console APIs directly. You may say PDCurses and old console apps have bugs for this, but why getch in msvcrt.dll can't produce the same keycode for CTRL+H ?

Try this:

python -c "import msvcrt;print(msvcrt.getch())"

and press CTRL+H.

At least, Windows Terminal should not break msvcrt, isn't it ?

@skywind3000 commented on GitHub (May 19, 2020): @DHowett Thanks for including this in milestone 1.1, @tasogare3710 , Vim doesn't require PDCurses, it uses Win32 console APIs directly. You may say PDCurses and old console apps have bugs for this, but why `getch` in msvcrt.dll can't produce the same keycode for `CTRL+H` ? Try this: python -c "import msvcrt;print(msvcrt.getch())" and press CTRL+H. At least, Windows Terminal should not break msvcrt, isn't it ?

claunia commented

@skywind3000 commented on GitHub (May 19, 2020):

@DHowett , the xterm app you are using are too old, you can try one of:

windows: Putty, MinTTY, XShell
linux: gnome-terminal
macos: iterm2, terminal.app

Most modern terminal apps send 0x08 for CTRL+H, 0x7f for BackSpace by default, and they provide options for customizing:

XShell's default:

PuTTY's default:

Terminal.app's default:

iTerm2's default:

I think I made my point.

@skywind3000 commented on GitHub (May 19, 2020): @DHowett , the xterm app you are using are too old, you can try one of: - windows: Putty, MinTTY, XShell - linux: gnome-terminal - macos: iterm2, terminal.app Most modern terminal apps send `0x08` for CTRL+H, `0x7f` for BackSpace by default, and they provide options for customizing: XShell's default: ![图片](https://user-images.githubusercontent.com/3035071/82300939-2166be80-99ea-11ea-817c-27d910bbdb94.png) PuTTY's default: ![图片](https://user-images.githubusercontent.com/3035071/82301050-48bd8b80-99ea-11ea-904c-9d3b40310f3f.png) Terminal.app's default: ![图片](https://user-images.githubusercontent.com/3035071/82301930-8242c680-99eb-11ea-8ccc-07cbfef071a3.png) iTerm2's default: ![图片](https://user-images.githubusercontent.com/3035071/82301321-a520ab00-99ea-11ea-871c-662899922447.png) I think I made my point.

claunia commented

@DHowett commented on GitHub (May 19, 2020):

@skywind3000 None of those configures what ctrl+backspace does, which is the issue we are discussing. I know that backspace is configurable.

@DHowett commented on GitHub (May 19, 2020): @skywind3000 None of those configures what _ctrl+backspace_ does, which is the issue we are discussing. I know that _backspace_ is configurable.

claunia commented

@GoodClover commented on GitHub (Jun 2, 2020):

I tested this running cmd prompt in Windows Terminal, thought it might be useful here.

That keyboard section of the table is what I typed.

The common section of the table is what is "correct" for that keycode - not necacerily the most common usage.

Keyboard	Decimal	Hex	Binary	Unicode	Common
Backspace	8	8	1000	Backspace	Backspace, ^h
^?	8	8	1000	Backspace	Backspace, ^h
^h	127	7F	1111111	Delete	Delete, ^?
Delete	330	14A	101001010	Ŋ	LATIN CAPITAL LETTER ENG
^Backspace	127	7F	1111111	Delete	Delete, ^?
^Delete	527	20F	100000111	ȏ	LATIN SMALL LETTER O WITH INVERTED BREVE

Following the pattern that ^a ^b ^c are 0x1 0x2 and 0x3, I would assume that ^h would be 0x8, it is not.

^h should be identical to Backspace.

These kinds of "errors" appear to happen with other keys as well. This isn't always a bad thing as keyboards keys meanings do evolve over time. And for correct usage the key may have to change what it represents.

However here is what I think the "correct" table would be:

Keyboard	Decimal	Hex	Binary	Unicode	Common
Backspace	8	8	1000	Backspace	Backspace, ^h
^?	127	7F	1111111	Delete	Delete ^?
^h	8	8	1000	Backspace	Backspace, ^h
Delete	127	7F	1111111	Delete	Delete ^?

^Backspace and ^Delete don't have a standard for what the should be as far as I know.

EDIT: My markdown was broken.
EDIT 2: Some other oddities:

Keyboard	Output	Out Hex	Expected	Exp Hex
^H	^?	7F	^H	8
^J	ȑ	211	^J	A
^M	^J	A	^M	D
^Enter	ȑ	211	^Enter	N/A

(I can't test ^V for obvious reasons)

@GoodClover commented on GitHub (Jun 2, 2020): I tested this running cmd prompt in Windows Terminal, thought it might be useful here. That keyboard section of the table is what I typed. The common section of the table is what is "correct" for that keycode - not necacerily the most common usage. | Keyboard | Decimal | Hex | Binary | Unicode | Common | | ---------: | ------: | --: | --------: | --------- | ----------------------------------------| | Backspace | 8 | 8 | 1000 | Backspace | Backspace, ^h | | ^? | 8 | 8 | 1000 | Backspace | Backspace, ^h | | ^h | 127 | 7F | 1111111 | Delete | Delete, ^? | | Delete | 330 | 14A | 101001010 | Ŋ | LATIN CAPITAL LETTER ENG | | ^Backspace | 127 | 7F | 1111111 | Delete | Delete, ^? | | ^Delete | 527 | 20F | 100000111 | ȏ | LATIN SMALL LETTER O WITH INVERTED BREVE | Following the pattern that ^a ^b ^c are 0x1 0x2 and 0x3, I would assume that ^h would be 0x8, it is not. ^h should be identical to Backspace. These kinds of "errors" appear to happen with other keys as well. This isn't always a bad thing as keyboards keys meanings do evolve over time. And for correct usage the key may have to change what it represents. However here is what I think the "correct" table would be: | Keyboard | Decimal | Hex | Binary | Unicode | Common| | --------: | ------: | --: | ------: | --------- | ------------- | | Backspace | 8 | 8 | 1000 | Backspace | Backspace, ^h | | ^? | 127 | 7F | 1111111 | Delete | Delete ^? | | ^h | 8 | 8 | 1000 | Backspace | Backspace, ^h | | Delete | 127 | 7F | 1111111 | Delete | Delete ^? | ^Backspace and ^Delete don't have a standard for what the should be as far as I know. EDIT: My markdown was broken. EDIT 2: Some other oddities: | Keyboard | Output | Out Hex | Expected | Exp Hex | | -----------| ---------|---------:|------------|---------:| | ^H | ^? | 7F | ^H | 8 | | ^J | ȑ | 211| ^J | A | | ^M | ^J | A | ^M | D | | ^Enter | ȑ | 211 | ^Enter | N/A | (I can't test ^V for obvious reasons)

claunia commented

@skywind3000 commented on GitHub (Jun 2, 2020):

objection, I use CTRL+h and BackSpace in vim for different purpose,
CTRL+h/j/k/l is always for windows switching in my vimrc and BackSpace is for invalidate client area.
their can't share the same keycode. BackSpace uses 127 by default in many modern terminals.

@skywind3000 commented on GitHub (Jun 2, 2020): objection, I use CTRL+h and BackSpace in vim for different purpose, CTRL+h/j/k/l is always for windows switching in my vimrc and BackSpace is for invalidate client area. their can't share the same keycode. BackSpace uses 127 by default in many modern terminals.

claunia commented

@GoodClover commented on GitHub (Jun 2, 2020):

This isn't always a bad thing as keyboards keys meanings do evolve over time. And for correct usage the key may have to change what it represents.

I didn't mean that it should be backspace I was just saying that due to the way the Control key works Ctrl+H ends up being hex 8 which is back space. The ctrl key wasn't intended to be used the way it is today and that causes issues. It was intended for entering control codes.

If you look at Unicode chart 0
Backspace has the code 0x8.

Now look at this:

Keyboard	Hex	Hex Meaning
^A	01	Start of Heading
^B	02	Start of Text
^C	03	End of Text
^D	04	End of Transmission

See the pattern?
Following this ^H would be 08
But this would cause issues as that means Backspace and that character is still in common usage.
Therefore:
^H has been replaced with 7f (127) meaning delete.
^? has been replaced with 08 (8) meaning backspace.
Delete has been replaced with 14a (330) meaning "Ŋ".
Etcetera.

To make it clear:
^H literally means backspace.
^H and ^? have been swapped.

Another example if you need it:
^I (i not L) is 9
9 means Horizontal Tabulation (Known as tab).
Try it, ^I will usually give you a tab.

I'm not on either side of the argument, just pointing out what you seem to have missed and that is what the control key actually does.

@GoodClover commented on GitHub (Jun 2, 2020): > This isn't always a bad thing as keyboards keys meanings do evolve over time. And for correct usage the key may have to change what it represents. I didn't mean that it should be backspace I was just saying that due to the way the Control key works Ctrl+H ends up being hex 8 which is back space. The ctrl key wasn't intended to be used the way it is today and that causes issues. It was intended for entering control codes. If you look at [Unicode chart 0](https://www.unicode.org/charts/PDF/U0000.pdf) Backspace has the code 0x8. Now look at this: | Keyboard | Hex | Hex Meaning | | ---------- | ----: | ------------------ | | ^A | 01 | Start of Heading | | ^B | 02 | Start of Text | | ^C | 03 | End of Text | | ^D | 04 | End of Transmission | See the pattern? Following this ^H would be 08 But this would cause issues as that means Backspace and that character is still in common usage. Therefore: ^H has been replaced with 7f (127) meaning delete. ^? has been replaced with 08 (8) meaning backspace. Delete has been replaced with 14a (330) meaning "Ŋ". Etcetera. To make it clear: ^H *literally* means backspace. ^H and ^? have been swapped. Another example if you need it: ^I (i not L) is 9 9 means Horizontal Tabulation (Known as tab). Try it, ^I will usually give you a tab. I'm not on either side of the argument, just pointing out what you seem to have missed and that is what the control key actually does.

claunia commented

@GoodClover commented on GitHub (Jun 2, 2020):

Though of something. Here it is:
Imagine each letter being replaced by its place in the alphabet.
e.g A=1, B=2, C=3
Now to get that letter in ASCII/Unicode you add 64 (1000000) to it.
To get it lowercase add 96 (1100000) (another 32) to it.
Using that number by itself gives you a control code.
To get this control code your press the (guess what!) control key.

This causes issues using Ctrl for shortcuts as you don't want the control code as the key does, you want your shortcut.
A lot of control codes aren't used anymore so its usually ok though.
For the ones that do cause issues they get re-wired sometimes. (Like ^H and ^J) to other symbols that don't really get used (Like ȑ and ȏ).

I'm not saying this is the right thing to do, but it's what is done.

@GoodClover commented on GitHub (Jun 2, 2020): Though of something. Here it is: Imagine each letter being replaced by its place in the alphabet. e.g A=1, B=2, C=3 Now to get that letter in ASCII/Unicode you add 64 (1000000) to it. To get it lowercase add 96 (1100000) (another 32) to it. Using that number by itself gives you a control code. To get this control code your press the (guess what!) control key. This causes issues using Ctrl for shortcuts as you don't want the control code as the key does, you want your shortcut. A lot of control codes aren't used anymore so its usually ok though. For the ones that do cause issues they get re-wired sometimes. (Like ^H and ^J) to other symbols that don't really get used (Like ȑ and ȏ). I'm not saying this is the right thing to do, but it's what is done.

claunia commented

@BDisp commented on GitHub (May 31, 2021):

A single sample which fail with Windows Terminal (PowerShell, cmd and Windows PowerShell) but not will fail if using WSL inside Windows Terminal. Using the dotnet "System.Console.ReadKey", pressing the Enter key, the ConsoleKeyInfo returns the right information, using PowerShell or cmd, without using the Windows Terminal, i.e Key = ConsoleKey.Enter and KeyChar = 13'\r'. But using the Windows Terminal the information is Key = 0 and KeyChar = 13'\r', which is interpreted as Ctrl + M, because as the Key = 0 is assumed there was pressed the Control key and 13 is the index starting from 1 to 26 (A to Z), which is 'M'. The WSL inside the Windows Terminal is working as expected. Why the ConsoleKey.Enter is not passed to the Windows, inside the Windows Terminal, as same it is passed to WSL?

@BDisp commented on GitHub (May 31, 2021): A single sample which fail with `Windows Terminal` (`PowerShell`,` cmd` and `Windows PowerShell`) but not will fail if using `WSL` inside `Windows Terminal`. Using the dotnet "`System.Console.ReadKey`", pressing the `Enter` key, the `ConsoleKeyInfo` returns the right information, using `PowerShell` or `cmd`, without using the `Windows Terminal`, i.e `Key = ConsoleKey.Enter` and `KeyChar = 13'\r'`. But using the `Windows Terminal` the information is `Key = 0` and `KeyChar = 13'\r'`, which is interpreted as` Ctrl + M`, because as the `Key = 0` is assumed there was pressed the Control key and 13 is the index starting from `1 to 26` (`A to Z`), which is `'M'`. The `WSL` inside the `Windows Terminal` is working as expected. Why the `ConsoleKey.Enter` is not passed to the `Windows`, inside the `Windows Terminal`, as same it is passed to `WSL`?

claunia commented

@Toxic-Waste- commented on GitHub (Jul 30, 2021):

Is there a fix or a way to remap this in the future planned?

I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections.

Any update on this?

@Toxic-Waste- commented on GitHub (Jul 30, 2021): Is there a fix or a way to remap this in the future planned? I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections. Any update on this?

claunia commented

@ghost commented on GitHub (Aug 18, 2021):

Is there a fix or a way to remap this in the future planned?

I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections.

Any update on this?

Hi, I had the same problem and solved it using this custom setting:

{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }

@ghost commented on GitHub (Aug 18, 2021): > Is there a fix or a way to remap this in the future planned? > > I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections. > > Any update on this? Hi, I had the same problem and solved it using this custom setting: `{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }`

claunia commented

@sgk commented on GitHub (Aug 18, 2021):

Oh, I didn't know that such simple setting can solve the problem. I added the following lines in my settings.json, and works fine.

{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" },
{ "command": { "action": "sendInput", "input": "\u007f" }, "keys": "delete" }

@sgk commented on GitHub (Aug 18, 2021): Oh, I didn't know that such simple setting can solve the problem. I added the following lines in my settings.json, and works fine. ``` { "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }, { "command": { "action": "sendInput", "input": "\u007f" }, "keys": "delete" } ```

claunia commented

@Toxic-Waste- commented on GitHub (Aug 19, 2021):

Is there a fix or a way to remap this in the future planned?
I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections.
Any update on this?

Hi, I had the same problem and solved it using this custom setting:

{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }

Not all heroes wear capes, you are my hero today sir :)

@Toxic-Waste- commented on GitHub (Aug 19, 2021): > > > > Is there a fix or a way to remap this in the future planned? > > I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections. > > Any update on this? > > Hi, I had the same problem and solved it using this custom setting: > > `{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }` Not all heroes wear capes, you are my hero today sir :)

claunia commented

@xoofx commented on GitHub (Dec 31, 2021):

@skywind3000 None of those configures what ctrl+backspace does, which is the issue we are discussing. I know that backspace is configurable.

I have a question for Unix folks: Is it important that CTRL+Backspace maps to \x8 or could it map to e.g \x17 (so CTRL+W, Backword) in the specific case of Windows Terminal? (when the console is configured with ENABLE_VIRTUAL_TERMINAL_INPUT, see #4949). Seems that many terminals don't allow to remap CTRL+Backspace anyway...

@xoofx commented on GitHub (Dec 31, 2021): > @skywind3000 None of those configures what _ctrl+backspace_ does, which is the issue we are discussing. I know that _backspace_ is configurable. I have a question for Unix folks: Is it important that `CTRL+Backspace` maps to `\x8` or could it map to e.g `\x17` (so `CTRL+W`, Backword) in the specific case of Windows Terminal? (when the console is configured with `ENABLE_VIRTUAL_TERMINAL_INPUT`, see #4949). Seems that many terminals don't allow to remap `CTRL+Backspace` anyway...

claunia commented