starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-05-20 22:06:56 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Control key modifier chords interpreted incorrectly when using custom keyboard layout #17733

New Issue
Closed
opened 2026-01-31 05:51:42 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 05:51:42 +00:00
Owner
Copy Link

Originally created by @cheryllium on GitHub (Jun 18, 2022).

Windows Terminal version

1.13.11431.0

Windows build number

10.0.19044.0

Other Software

NOTE: I've also reproduced the issue in a separate environment using Ubuntu 20.04 in WSL v1.

Steps to reproduce

Prerequisite: set up environment

  1. Install Programmer Dvorak using linked binary and add it to your keyboard layouts so that it can be enabled as you wish.
  2. Install WSL with wsl --install and install Ubuntu 22.04 from the Microsoft store

Reproduce the issue

I will give two examples of the problem. However, these are not the only cases where behavior is incorrect. I thought this may be sufficient for now, but if more examples would be helpful, let me know and I'll spend some time compiling a longer list.

  1. Open Windows Terminal tab into Ubuntu WSL
  2. Make sure you are in Programmer Dvorak keyboard layout.
  3. Run showkey -a which will allow you to type on the keyboard. It will display information about the keys typed in real time.

Example 1:

  1. Type ] (on physical QWERTY keyboards, hit the 0 key)
  2. Type Ctrl + ] (press same key while holding Ctrl)

Example 2:

  1. Type [ (on physical QWERTY keyboards, hit the 2 key)
  2. Type Ctrl + [ (press same key while holding Ctrl)

Expected Behavior

$ showkey -a

Press any keys - Ctrl-D will terminate this program

[        91 0133 0x5b
^[       27 0033 0x1b
]        93 0135 0x5d
^]       29 0035 0x1d

When the control key is held, it should display ^ followed by the key that was pressed, as above.

Actual Behavior

$ showkey -a

Press any keys - Ctrl-D will terminate this program

[        91 0133 0x5b
^_       31 0037 0x1f
]        93 0135 0x5d
^^       30 0036 0x1e

In this output, it shows Windows Terminal interprets Ctrl + [ as Ctrl + _, and interprets Ctrl + ] as Ctrl + ^ instead.

I considered this could be an issue with Programmer Dvorak, WSL, or otherwise. But after some testing, I think it is a Windows Terminal bug because:

  • I get expected behavior in multiple Linux-only environments I have tried
  • I get expected behavior in Windows Command Prompt, which implies Programmer Dvorak is getting interpreted correctly by Windows itself (so, it is working correctly on the OS level)

I am more than happy to gather/provide further information within my capabilities, clarify anything in this report, and help out as much as I can to debug and fix this problem.
I am currently attempting to set up a development environment to try and debug this further, but I have no experience with this project or Windows application development, so realistically I won't be able to help implement a fix at this time.

Originally created by @cheryllium on GitHub (Jun 18, 2022). ### Windows Terminal version 1.13.11431.0 ### Windows build number 10.0.19044.0 ### Other Software - Programmer Dvorak keyboard layout https://www.kaufmann.no/roland/dvorak/ installed using binary: [kbddvp-1_2_8-i386.exe (76 KiB)](https://www.kaufmann.no/downloads/winnt/kbddvp-1_2_8-i386.exe) (MD5sum: 4036147b2b637addcac3fb1fe04a29e2) - Windows Subsystem for Linux with Ubuntu-22.04 for WSL 2 (WSL was installed using `wsl --install` command, Ubuntu was installed from Microsoft Store) NOTE: I've also reproduced the issue in a separate environment using Ubuntu 20.04 in WSL v1. ### Steps to reproduce #### Prerequisite: set up environment 1. Install Programmer Dvorak using linked binary and add it to your keyboard layouts so that it can be enabled as you wish. 1. Install WSL with `wsl --install` and install Ubuntu 22.04 from the Microsoft store #### Reproduce the issue I will give two examples of the problem. However, these are not the only cases where behavior is incorrect. I thought this may be sufficient for now, but if more examples would be helpful, let me know and I'll spend some time compiling a longer list. 1. Open Windows Terminal tab into Ubuntu WSL 1. Make sure you are in Programmer Dvorak keyboard layout. 1. Run `showkey -a` which will allow you to type on the keyboard. It will display information about the keys typed in real time. Example 1: 1. Type `]` (on physical QWERTY keyboards, hit the `0` key) 1. Type `Ctrl + ]` (press same key while holding Ctrl) Example 2: 1. Type `[` (on physical QWERTY keyboards, hit the `2` key) 3. Type `Ctrl + [` (press same key while holding Ctrl) ### Expected Behavior ``` $ showkey -a Press any keys - Ctrl-D will terminate this program [ 91 0133 0x5b ^[ 27 0033 0x1b ] 93 0135 0x5d ^] 29 0035 0x1d ``` When the control key is held, it should display `^` followed by the key that was pressed, as above. ### Actual Behavior ``` $ showkey -a Press any keys - Ctrl-D will terminate this program [ 91 0133 0x5b ^_ 31 0037 0x1f ] 93 0135 0x5d ^^ 30 0036 0x1e ``` In this output, it shows Windows Terminal interprets `Ctrl + [` as `Ctrl + _`, and interprets `Ctrl + ]` as `Ctrl + ^` instead. I considered this could be an issue with Programmer Dvorak, WSL, or otherwise. But after some testing, I think it is a Windows Terminal bug because: - I get expected behavior in multiple Linux-only environments I have tried - I get expected behavior in Windows Command Prompt, which implies Programmer Dvorak is getting interpreted correctly by Windows itself (so, it is working correctly on the OS level) _I am more than happy to gather/provide further information within my capabilities, clarify anything in this report, and help out as much as I can to debug and fix this problem. I am currently attempting to set up a development environment to try and debug this further, but I have no experience with this project or Windows application development, so realistically I won't be able to help implement a fix at this time._
claunia commented 2026-01-31 05:51:45 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 18, 2022):

Thanks for the comprehensive bug report!

If you open up your settings.json (using the button at the bottom left of Settings) and add "experimental.input.forceVT": true to profiles.defaults, does it fix your issue? If so, we've got some solid thoughts on what's happening. 😄

(Like this:

{
    // ...
    "profiles": {
        "defaults": {
            "experimental.input.forceVT": true,
            // ...
        }
    }
}

)

@DHowett commented on GitHub (Jun 18, 2022): Thanks for the comprehensive bug report! If you open up your `settings.json` (using the button at the bottom left of Settings) and add `"experimental.input.forceVT": true` to `profiles.defaults`, does it fix your issue? If so, we've got some solid thoughts on what's happening. :smile: (Like this: ```jsonc { // ... "profiles": { "defaults": { "experimental.input.forceVT": true, // ... } } } ``` )
claunia commented 2026-01-31 05:51:46 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 18, 2022):

Ah, after doing so (and saving the file) you'll need to open a new tab.

@DHowett commented on GitHub (Jun 18, 2022): Ah, after doing so (and saving the file) you'll need to open a new tab.
claunia commented 2026-01-31 05:51:46 +00:00
Author
Owner
Copy Link

@cheryllium commented on GitHub (Jun 18, 2022):

@DHowett Thank you for the suggestion. I added the line, closed and re-opened Windows Terminal, and unfortunately am still seeing the incorrect behavior.

@cheryllium commented on GitHub (Jun 18, 2022): @DHowett Thank you for the suggestion. I added the line, closed and re-opened Windows Terminal, and unfortunately am still seeing the incorrect behavior.
claunia commented 2026-01-31 05:51:47 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 18, 2022):

That's actually really great news. Okay. Next, can you capture a trace with the debug tap?

It would be best if you turn that forceVT feature back off before you do this. :)

@DHowett commented on GitHub (Jun 18, 2022): That's actually really great news. Okay. Next, can you capture a trace with the [debug tap](https://github.com/microsoft/terminal/wiki/Enabling-the-debug-tap)? It would be best if you turn that `forceVT` feature back off before you do this. :)
claunia commented 2026-01-31 05:51:48 +00:00
Author
Owner
Copy Link

@cheryllium commented on GitHub (Jun 18, 2022):

@DHowett Okay, got it. Here's the output, and screenshot for clarity.

␛[?9001h␛[?25l␛[2J␛[m␛[H␛]0;Ubuntu␣22.04␣LTS␇␛[?25h␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[?2004h␛[32m␛[1mcheshire@DESKTOP-SHVHL0M␛[m:␛[34m␛[1m~␛[m$␣␛]0;cheshire@DESKTOP-SHVHL0M:␣~␇␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;0;1;1_␛[18;56;0;0;0;1_␛[83;39;115;1;0;1_␛[83;39;115;0;0;1_s␛[72;36;104;1;0;1_␛[72;36;104;0;0;1_h␛[79;31;111;1;0;1_␛[79;31;111;0;0;1_o␛[87;51;119;1;0;1_␛[87;51;119;0;0;1_w␛[75;47;107;1;0;1_␛[75;47;107;0;0;1_k␛[69;32;101;1;0;1_␛[69;32;101;0;0;1_e␛[89;20;121;1;0;1_␛[89;20;121;0;0;1_y␛[32;57;32;1;0;1_␛[32;57;32;0;0;1_␣␛[189;40;45;1;0;1_␛[189;40;45;0;0;1_-␛[65;30;97;1;0;1_␛[65;30;97;0;0;1_a␛[13;28;13;1;0;1_␛[13;28;13;0;0;1_␛[?2004l␛[?25l␛[3;1HPress␣any␣keys␣-␣Ctrl-D␣will␣terminate␣this␣program␛[5;1H␛[?25h␛[55;3;91;1;0;1_␛[55;3;91;0;0;1_[␣␛[6C␣91␣0133␣0x5b␍␊␛[17;29;0;1;8;1_␛[55;3;27;1;8;1_␛[55;3;27;0;8;1_^_␣␛[5C␣31␣0037␣0x1f␍␊␛[17;29;0;0;0;1_␛[54;11;93;1;0;1_␛[54;11;93;0;0;1_]␣␛[6C␣93␣0135␣0x5d␍␊␛[17;29;0;1;8;1_␛[54;11;29;1;8;1_␛[54;11;29;0;8;1_^^␣␛[5C␣30␣0036␣0x1e␍␊␛[17;29;0;0;0;1_␛[17;29;0;1;8;1_␛[68;35;4;1;8;1_␛[68;35;4;0;8;1_␛[?2004h^D␣␛[5C␣␣4␣0004␣0x04␛[32m␛[1m␍␊cheshire@DESKTOP-SHVHL0M␛[m:␛[34m␛[1m~␛[m$␣␛[17;29;0;0;0;1_

image

@cheryllium commented on GitHub (Jun 18, 2022): @DHowett Okay, got it. Here's the output, and screenshot for clarity. ``` ␛[?9001h␛[?25l␛[2J␛[m␛[H␛]0;Ubuntu␣22.04␣LTS␇␛[?25h␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[?2004h␛[32m␛[1mcheshire@DESKTOP-SHVHL0M␛[m:␛[34m␛[1m~␛[m$␣␛]0;cheshire@DESKTOP-SHVHL0M:␣~␇␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;1;3;1_␛[18;56;0;0;1;1_␛[18;56;0;0;0;1_␛[83;39;115;1;0;1_␛[83;39;115;0;0;1_s␛[72;36;104;1;0;1_␛[72;36;104;0;0;1_h␛[79;31;111;1;0;1_␛[79;31;111;0;0;1_o␛[87;51;119;1;0;1_␛[87;51;119;0;0;1_w␛[75;47;107;1;0;1_␛[75;47;107;0;0;1_k␛[69;32;101;1;0;1_␛[69;32;101;0;0;1_e␛[89;20;121;1;0;1_␛[89;20;121;0;0;1_y␛[32;57;32;1;0;1_␛[32;57;32;0;0;1_␣␛[189;40;45;1;0;1_␛[189;40;45;0;0;1_-␛[65;30;97;1;0;1_␛[65;30;97;0;0;1_a␛[13;28;13;1;0;1_␛[13;28;13;0;0;1_␛[?2004l␛[?25l␛[3;1HPress␣any␣keys␣-␣Ctrl-D␣will␣terminate␣this␣program␛[5;1H␛[?25h␛[55;3;91;1;0;1_␛[55;3;91;0;0;1_[␣␛[6C␣91␣0133␣0x5b␍␊␛[17;29;0;1;8;1_␛[55;3;27;1;8;1_␛[55;3;27;0;8;1_^_␣␛[5C␣31␣0037␣0x1f␍␊␛[17;29;0;0;0;1_␛[54;11;93;1;0;1_␛[54;11;93;0;0;1_]␣␛[6C␣93␣0135␣0x5d␍␊␛[17;29;0;1;8;1_␛[54;11;29;1;8;1_␛[54;11;29;0;8;1_^^␣␛[5C␣30␣0036␣0x1e␍␊␛[17;29;0;0;0;1_␛[17;29;0;1;8;1_␛[68;35;4;1;8;1_␛[68;35;4;0;8;1_␛[?2004h^D␣␛[5C␣␣4␣0004␣0x04␛[32m␛[1m␍␊cheshire@DESKTOP-SHVHL0M␛[m:␛[34m␛[1m~␛[m$␣␛[17;29;0;0;0;1_ ``` ![image](https://user-images.githubusercontent.com/5027241/174412903-ba6522b1-dd6e-4261-a1a9-823d47627195.png)
claunia commented 2026-01-31 05:51:48 +00:00
Author
Owner
Copy Link

@cheryllium commented on GitHub (Jun 28, 2022):

Hi, just wondering when this issue will be triaged? Thank you.

@cheryllium commented on GitHub (Jun 28, 2022): Hi, just wondering when this issue will be triaged? Thank you.
claunia commented 2026-01-31 05:51:49 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 6, 2022):

Sorry, we've been a little underwater as far as the triage queue goes. #4885 might be enlightening.

the above investigation into WM_CHAR messages eventually lead to me figuring out what was wrong: I diligently compared my keyboard layout to the US International layout using a keyboard layout disassembler and found out that Terminal works fine with the latter because it contains explicit character codes for ^@, ^[, ^\, ^], ^^ and ^_.

As it turns out, the Windows keyboard system generates control character WM_CHAR messages automatically for ^A-^Z even when the keyboard layout contains no mappings. However, this doesn't happen for the six remaining ones listed above. That's the reason Terminal saw no WM_CHAR messages.

What made it confusing was that these key combinations do work in the normal Windows console. Since it also doesn't get any WM_CHAR messages (I checked), it must synthesize those control characters from the WM_KEYDOWN/WM_KEYUP messages by itself.

It'll take a while to decompose those input sequences into the individual KEY_EVENTs[1], but I bet it's a similar root cause here.

[1]: I really should make a tool for that...

Everything before `showkey` starts
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;1;3;1_
  • ␛[18;56;0;0;1;1_
  • ␛[18;56;0;0;0;1_
  • ␛[83;39;115;1;0;1_
  • ␛[83;39;115;0;0;1_
  • ␛[72;36;104;1;0;1_
  • ␛[72;36;104;0;0;1_
  • h␛[79;31;111;1;0;1_
  • ␛[79;31;111;0;0;1_
  • ␛[87;51;119;1;0;1_
  • ␛[87;51;119;0;0;1_
  • ␛[75;47;107;1;0;1_
  • ␛[75;47;107;0;0;1_
  • ␛[69;32;101;1;0;1_
  • ␛[69;32;101;0;0;1_
  • ␛[89;20;121;1;0;1_
  • ␛[89;20;121;0;0;1_
  • ␛[32;57;32;1;0;1_
  • ␛[32;57;32;0;0;1_
  • ␛[189;40;45;1;0;1_
  • ␛[189;40;45;0;0;1_
  • ␛[65;30;97;1;0;1_
  • ␛[65;30;97;0;0;1_
  • ␛[13;28;13;1;0;1_
  • ␛[13;28;13;0;0;1_
  • ␛[55;3;91;1;0;1_
  • ␛[55;3;91;0;0;1_
  • ␛[17;29;0;1;8;1_
  • ␛[55;3;27;1;8;1_
  • ␛[55;3;27;0;8;1_
  • ^_
  • ␛[17;29;0;0;0;1_
  • ␛[54;11;93;1;0;1_
  • ␛[54;11;93;0;0;1_
  • ␛[17;29;0;1;8;1_
  • ␛[54;11;29;1;8;1_
  • ␛[54;11;29;0;8;1_
  • ␛[17;29;0;0;0;1_
  • ␛[17;29;0;1;8;1_
  • ␛[68;35;4;1;8;1_
  • ␛[68;35;4;0;8;1_
  • ␛[17;29;0;0;0;1_
@zadjii-msft commented on GitHub (Jul 6, 2022): Sorry, we've been a little underwater as far as the triage queue goes. #4885 might be enlightening. > the above investigation into `WM_CHAR` messages eventually lead to me figuring out what was wrong: I diligently compared my keyboard layout to the US International layout using a [keyboard layout disassembler](https://github.com/grompe/kbdasm) and found out that Terminal works fine with the latter because it contains explicit character codes for `^@`, `^[`, `^\`, `^]`, `^^` and `^_`. > > As it turns out, the Windows keyboard system generates control character `WM_CHAR` messages automatically for `^A`-`^Z` even when the keyboard layout contains no mappings. However, this doesn't happen for the six remaining ones listed above. That's the reason Terminal saw no `WM_CHAR` messages. > > What made it confusing was that these key combinations do work in the normal Windows console. Since it also doesn't get any `WM_CHAR` messages (I checked), it must synthesize those control characters from the `WM_KEYDOWN`/`WM_KEYUP` messages by itself. It'll take a while to decompose those input sequences into the individual KEY_EVENTs[1], but I bet it's a similar root cause here. [1]: _I really should make a tool for that..._ <details> <summary>Everything before `showkey` starts</summary> * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;1;3;1_` * `␛[18;56;0;0;1;1_` * `␛[18;56;0;0;0;1_` * `␛[83;39;115;1;0;1_` * `␛[83;39;115;0;0;1_` * `␛[72;36;104;1;0;1_` * `␛[72;36;104;0;0;1_` * `h␛[79;31;111;1;0;1_` * `␛[79;31;111;0;0;1_` * `␛[87;51;119;1;0;1_` * `␛[87;51;119;0;0;1_` * `␛[75;47;107;1;0;1_` * `␛[75;47;107;0;0;1_` * `␛[69;32;101;1;0;1_` * `␛[69;32;101;0;0;1_` * `␛[89;20;121;1;0;1_` * `␛[89;20;121;0;0;1_` * `␛[32;57;32;1;0;1_` * `␛[32;57;32;0;0;1_` * `␛[189;40;45;1;0;1_` * `␛[189;40;45;0;0;1_` * `␛[65;30;97;1;0;1_` * `␛[65;30;97;0;0;1_` * `␛[13;28;13;1;0;1_` * `␛[13;28;13;0;0;1_` </details> * `␛[55;3;91;1;0;1_` * `␛[55;3;91;0;0;1_` * `␛[17;29;0;1;8;1_` * `␛[55;3;27;1;8;1_` * `␛[55;3;27;0;8;1_` * `^_` * `␛[17;29;0;0;0;1_` * `␛[54;11;93;1;0;1_` * `␛[54;11;93;0;0;1_` * `␛[17;29;0;1;8;1_` * `␛[54;11;29;1;8;1_` * `␛[54;11;29;0;8;1_` * `␛[17;29;0;0;0;1_` * `␛[17;29;0;1;8;1_` * `␛[68;35;4;1;8;1_` * `␛[68;35;4;0;8;1_` * `␛[17;29;0;0;0;1_`
claunia commented 2026-01-31 05:51:49 +00:00
Author
Owner
Copy Link

@cheryllium commented on GitHub (Jul 10, 2022):

@zadjii-msft Thanks for the update and additional information. So if I understand correctly, the proposed fix would be to have Windows Terminal synthesize these key chords in the same way that Windows Console handles them?

@cheryllium commented on GitHub (Jul 10, 2022): @zadjii-msft Thanks for the update and additional information. So if I understand correctly, the proposed fix would be to have Windows Terminal synthesize these key chords in the same way that Windows Console handles them?
claunia commented 2026-01-31 05:51:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 13, 2022):

I'm not sure that it'll ever be possible for the Terminal to do things the same way the console does - they have pretty different input stacks. The read I got from #4885 was that there ultimately was a bug in the keyboard layout that should be resolved, that was only noticeable in the Terminal.

@zadjii-msft commented on GitHub (Jul 13, 2022): I'm not sure that it'll ever be possible for the Terminal to do things the same way the console does - they have pretty different input stacks. The read I got from #4885 was that there ultimately was a bug in the keyboard layout that should be resolved, that was only noticeable in the Terminal.
claunia commented 2026-01-31 05:51:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 13, 2022):

  • ␛[55;3;91;1;0;1_
    • Vk: 7 key
    • Sc: 3
    • Uc: '['
    • Kd: down`
    • Cs: 0
  • ␛[55;3;91;0;0;1_
    • Vk: 7 key
    • Sc: 3
    • Uc: '['
    • Kd: up`
    • Cs: 0
  • ␛[17;29;0;1;8;1_
    • Vk: VK_CONTROL
    • Sc: 29
    • Uc: 0
    • Kd: down`
    • Cs: 8
  • ␛[55;3;27;1;8;1_
    • Vk: 7 key
    • Sc: 3
    • Uc: 27
    • Kd: down`
    • Cs: 8
  • ␛[55;3;27;0;8;1_
    • Vk: 7 key
    • Sc: 3
    • Uc: 27
    • Kd: up`
    • Cs: 8
  • ^_
  • ␛[17;29;0;0;0;1_
    • Vk: VK_CONTROL
    • Sc: 29
    • Uc: 0
    • Kd: up`
    • Cs: 0
  • ␛[54;11;93;1;0;1_
    • Vk: 6 key
    • Sc: 11
    • Uc: ']'
    • Kd: down`
    • Cs: 0
  • ␛[54;11;93;0;0;1_
    • Vk: 6 key
    • Sc: 11
    • Uc: ']'
    • Kd: up`
    • Cs: 0
  • ␛[17;29;0;1;8;1_
    • Vk: VK_CONTROL
    • Sc: 29
    • Uc: 0
    • Kd: down`
    • Cs: 8
  • ␛[54;11;29;1;8;1_
    • Vk: 6 key
    • Sc: 11
    • Uc: 29
    • Kd: down`
    • Cs: 8
  • ␛[54;11;29;0;8;1_
    • Vk: 6 key
    • Sc: 11
    • Uc: 29
    • Kd: up`
    • Cs: 8
  • ␛[17;29;0;0;0;1_
    • Vk: VK_CONTROL
    • Sc: 29
    • Uc: 0
    • Kd: up`
    • Cs: 0
  • ␛[17;29;0;1;8;1_
    • Vk: VK_CONTROL
    • Sc: 29
    • Uc: 0
    • Kd: down`
    • Cs: 8
  • ␛[68;35;4;1;8;1_
    • Vk: D key
    • Sc: 35
    • Uc: 4
    • Kd: down`
    • Cs: 8
  • ␛[68;35;4;0;8;1_
    • Vk: D key
    • Sc: 35
    • Uc: 4
    • Kd: up`
    • Cs: 8
  • ␛[17;29;0;0;0;1_
    • Vk: VK_CONTROL
    • Sc: 29
    • Uc: 0
    • Kd: up`
    • Cs: 0
@zadjii-msft commented on GitHub (Jul 13, 2022): * `␛[55;3;91;1;0;1_` * `Vk`: 7 key * `Sc`: 3 * `Uc`: '[' * `Kd`: down` * `Cs`: 0 * `␛[55;3;91;0;0;1_` * `Vk`: 7 key * `Sc`: 3 * `Uc`: '[' * `Kd`: up` * `Cs`: 0 * `␛[17;29;0;1;8;1_` * `Vk`: VK_CONTROL * `Sc`: 29 * `Uc`: 0 * `Kd`: down` * `Cs`: 8 * `␛[55;3;27;1;8;1_` * `Vk`: 7 key * `Sc`: 3 * `Uc`: 27 * `Kd`: down` * `Cs`: 8 * `␛[55;3;27;0;8;1_` * `Vk`: 7 key * `Sc`: 3 * `Uc`: 27 * `Kd`: up` * `Cs`: 8 * `^_` * `␛[17;29;0;0;0;1_` * `Vk`: VK_CONTROL * `Sc`: 29 * `Uc`: 0 * `Kd`: up` * `Cs`: 0 * `␛[54;11;93;1;0;1_` * `Vk`: 6 key * `Sc`: 11 * `Uc`: ']' * `Kd`: down` * `Cs`: 0 * `␛[54;11;93;0;0;1_` * `Vk`: 6 key * `Sc`: 11 * `Uc`: ']' * `Kd`: up` * `Cs`: 0 * `␛[17;29;0;1;8;1_` * `Vk`: VK_CONTROL * `Sc`: 29 * `Uc`: 0 * `Kd`: down` * `Cs`: 8 * `␛[54;11;29;1;8;1_` * `Vk`: 6 key * `Sc`: 11 * `Uc`: 29 * `Kd`: down` * `Cs`: 8 * `␛[54;11;29;0;8;1_` * `Vk`: 6 key * `Sc`: 11 * `Uc`: 29 * `Kd`: up` * `Cs`: 8 * `␛[17;29;0;0;0;1_` * `Vk`: VK_CONTROL * `Sc`: 29 * `Uc`: 0 * `Kd`: up` * `Cs`: 0 * `␛[17;29;0;1;8;1_` * `Vk`: VK_CONTROL * `Sc`: 29 * `Uc`: 0 * `Kd`: down` * `Cs`: 8 * `␛[68;35;4;1;8;1_` * `Vk`: D key * `Sc`: 35 * `Uc`: 4 * `Kd`: down` * `Cs`: 8 * `␛[68;35;4;0;8;1_` * `Vk`: D key * `Sc`: 35 * `Uc`: 4 * `Kd`: up` * `Cs`: 8 * `␛[17;29;0;0;0;1_` * `Vk`: VK_CONTROL * `Sc`: 29 * `Uc`: 0 * `Kd`: up` * `Cs`: 0
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Input Help Wanted In-PR Issue-Bug Needs-Tag-Fix Product-Conpty Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17733
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?