starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Keyboard Issues with zsh: Keypad and Other Keys Not Functional. #21185

New Issue
Closed
opened 2026-01-31 07:35:41 +00:00 by claunia · 21 comments
claunia commented 2026-01-31 07:35:41 +00:00
Owner
Copy Link

Originally created by @ab2pentest on GitHub (Feb 2, 2024).

Windows Terminal version

1.20.10303.0

Windows build number

10.0.19045.3930

Other Software

zsh 5.9 (x86_64-debian-linux-gnu)

Steps to reproduce

I installed the latest preview version 1.20.10303.0, and now I'm experiencing issues with my keypad and some other keys. I use a French AZERTY keyboard, and the problem only occurs when I'm using zsh; everything works fine on bash for some reason.

Expected Behavior

No response

Actual Behavior

I have reinstalled Windows Terminal Preview Version 1.19.3172.0, and everything is working perfectly!

Originally created by @ab2pentest on GitHub (Feb 2, 2024). ### Windows Terminal version 1.20.10303.0 ### Windows build number 10.0.19045.3930 ### Other Software zsh 5.9 (x86_64-debian-linux-gnu) ### Steps to reproduce I installed the latest preview version 1.20.10303.0, and now I'm experiencing issues with my keypad and some other keys. I use a French AZERTY keyboard, and the problem only occurs when I'm using zsh; everything works fine on bash for some reason. ### Expected Behavior _No response_ ### Actual Behavior I have reinstalled Windows Terminal Preview Version 1.19.3172.0, and everything is working perfectly!
claunia commented 2026-01-31 07:35:43 +00:00
Author
Owner
Copy Link

@mveroone commented on GitHub (Feb 2, 2024):

Hi.
I've started having this issue today too, and I was able to fix ZSH by adding this in my zshrc, however i still have an Issue with 3 & 9 acting as PgDown & PgUp in vim so there's something strange that changed.

# Fix numpad not working
# 0 . Enter
bindkey -s "^[Op" "0"
bindkey -s "^[Ol" "."
bindkey -s "^[OM" "^M"
# 1 2 3
bindkey -s "^[Oq" "1"
bindkey -s "^[Or" "2"
bindkey -s "^[Os" "3"
# 4 5 6
bindkey -s "^[Ot" "4"
bindkey -s "^[Ou" "5"
bindkey -s "^[Ov" "6"
# 7 8 9
bindkey -s "^[Ow" "7"
bindkey -s "^[Ox" "8"
bindkey -s "^[Oy" "9"
# + -  * /
bindkey -s "^[Ok" "+"
bindkey -s "^[Om" "-"
bindkey -s "^[Oj" "*"
bindkey -s "^[Oo" "/"
@mveroone commented on GitHub (Feb 2, 2024): Hi. I've started having this issue today too, and I was able to fix ZSH by adding this in my zshrc, however i still have an Issue with 3 & 9 acting as PgDown & PgUp in `vim` so there's something strange that changed. ``` # Fix numpad not working # 0 . Enter bindkey -s "^[Op" "0" bindkey -s "^[Ol" "." bindkey -s "^[OM" "^M" # 1 2 3 bindkey -s "^[Oq" "1" bindkey -s "^[Or" "2" bindkey -s "^[Os" "3" # 4 5 6 bindkey -s "^[Ot" "4" bindkey -s "^[Ou" "5" bindkey -s "^[Ov" "6" # 7 8 9 bindkey -s "^[Ow" "7" bindkey -s "^[Ox" "8" bindkey -s "^[Oy" "9" # + - * / bindkey -s "^[Ok" "+" bindkey -s "^[Om" "-" bindkey -s "^[Oj" "*" bindkey -s "^[Oo" "/" ```
claunia commented 2026-01-31 07:35:43 +00:00
Author
Owner
Copy Link

@ab2pentest commented on GitHub (Feb 3, 2024):

@mveroone
Thank you for your reply. I am aware that this solution can address the issue, but I am still encountering problems with other keys on my keyboard. I am uncertain if there are additional keys affected, as I haven't tested all functionalities, which is not what I expected from Windows Terminal.

@ab2pentest commented on GitHub (Feb 3, 2024): @mveroone Thank you for your reply. I am aware that this solution can address the issue, but I am still encountering problems with other keys on my keyboard. I am uncertain if there are additional keys affected, as I haven't tested all functionalities, which is not what I expected from Windows Terminal.
claunia commented 2026-01-31 07:35:44 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 3, 2024):

Technically the keypad is working as intended. In version 1.20 we added support for Keypad Application Mode, which enables applications to differentiate between the keys on the numeric keypad and the corresponding numeric keys on the main keyboard. Both zsh and vim ask the terminal to enable that mode.

For zsh, the keypad keys aren't bound to anything by default, which is why they have no effect. For vim, most of the keys are assigned the same character values that you'd normally expect, except 9 and 3 appear to be bound to PageUp and PageDown. I'm not sure why that is - possibly because some of the original hardware terminals didn't have separate PageUp and PageDown keys.

I am still encountering problems with other keys on my keyboard.

@ab2pentest If those are not keypad keys, please let us know exactly which keys are not working for you, because that's likely a different issue.

@j4james commented on GitHub (Feb 3, 2024): Technically the keypad is working as intended. In version 1.20 we added support for [Keypad Application Mode](https://vt100.net/docs/vt510-rm/DECKPAM.html), which enables applications to differentiate between the keys on the numeric keypad and the corresponding numeric keys on the main keyboard. Both zsh and vim ask the terminal to enable that mode. For zsh, the keypad keys aren't bound to anything by default, which is why they have no effect. For vim, most of the keys are assigned the same character values that you'd normally expect, except `9` and `3` appear to be bound to PageUp and PageDown. I'm not sure why that is - possibly because some of the original hardware terminals didn't have separate PageUp and PageDown keys. > I am still encountering problems with other keys on my keyboard. @ab2pentest If those are not keypad keys, please let us know exactly which keys are not working for you, because that's likely a different issue.
claunia commented 2026-01-31 07:35:44 +00:00
Author
Owner
Copy Link

@dziban303 commented on GitHub (Feb 4, 2024):

So how can we turn support for Keypad Application Mode off, @j4james? I don't see any setting for it in the wt UI and I don't see anything about it in the json settings schema.

@dziban303 commented on GitHub (Feb 4, 2024): So how can we turn support for Keypad Application Mode off, @j4james? I don't see any setting for it in the wt UI and I don't see anything about it in the json settings schema.
claunia commented 2026-01-31 07:35:44 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 4, 2024):

@dziban303 Unfortunately it's not possible disable this kind of functionality from within the WT UI. But if the application you're using is built with the curses library, and you don't mind disabling it for all curses applications, then you should be able to fix the issue by modifying your terminfo as described here: https://stackoverflow.com/a/41336431

Otherwise for apps like vim and nano, I'm assuming you can at least rebind the keypad keys to whatever characters you want them to send.

That said, I am looking for a better way for WT to handle this.

@j4james commented on GitHub (Feb 4, 2024): @dziban303 Unfortunately it's not possible disable this kind of functionality from within the WT UI. But if the application you're using is built with the _curses_ library, and you don't mind disabling it for all _curses_ applications, then you should be able to fix the issue by modifying your terminfo as described here: https://stackoverflow.com/a/41336431 Otherwise for apps like vim and nano, I'm assuming you can at least rebind the keypad keys to whatever characters you want them to send. That said, I am looking for a better way for WT to handle this.
claunia commented 2026-01-31 07:35:44 +00:00
Author
Owner
Copy Link

@dziban303 commented on GitHub (Feb 4, 2024):

I'm sure you'll agree that it's totally unreasonable to make users remap ~17 keys in one or more programs, in every linux instance they use, to accommodate a feature which Google tells me can be disabled in other terminal programs like Putty with a checkbox.

@dziban303 commented on GitHub (Feb 4, 2024): I'm sure you'll agree that it's totally unreasonable to make users remap ~17 keys in one or more programs, in every linux instance they use, to accommodate a feature which Google tells me can be disabled in other terminal programs like Putty with a checkbox.
claunia commented 2026-01-31 07:35:45 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 4, 2024):

As I said, I am looking for a better way to handle this, but worst case we can just remove the functionality altogether if nobody wants it.

@j4james commented on GitHub (Feb 4, 2024): As I said, I am looking for a better way to handle this, but worst case we can just remove the functionality altogether if nobody wants it.
claunia commented 2026-01-31 07:35:45 +00:00
Author
Owner
Copy Link

@jtabox commented on GitHub (Feb 5, 2024):

Maybe I'm looking at the wrong places, but how can I bind the numpad keys to their corresponding characters in nano (i.e. restore the pre-1.20 functionality)? All I could find was how to bind shift-, control- and alt-key sequences, and even those only to specific functions in nano, not to text.

Otherwise yeah, +1 for the option to disable this functionality in an easy way, would be greatly appreciated. I'm sure there was a good reason for implementing it without the option of opting out, but it's been a bit jarring to have the cursor jump around or not do anything when I expected it to write a number after using the numpad keys.

@jtabox commented on GitHub (Feb 5, 2024): Maybe I'm looking at the wrong places, but how can I bind the numpad keys to their corresponding characters in nano (i.e. restore the pre-1.20 functionality)? All I could find was how to bind shift-, control- and alt-key sequences, and even those only to specific functions in nano, not to text. Otherwise yeah, +1 for the option to disable this functionality in an easy way, would be greatly appreciated. I'm sure there was a good reason for implementing it without the option of opting out, but it's been a bit jarring to have the cursor jump around or not do anything when I expected it to write a number after using the numpad keys.
claunia commented 2026-01-31 07:35:45 +00:00
Author
Owner
Copy Link

@dziban303 commented on GitHub (Feb 5, 2024):

This feature should be rolled back until a way to toggle it is arrived at. A line in the config file is fine, it doesn't need a bespoke UI element right away. And it should probably be disabled by default. Windows Terminal users have made it for years without it. I don't know how many users have been waiting for it to be implemented but I wager it's a smaller pool than that of people who need to use text editors.

@jtabox The easiest workaround is here: https://stackoverflow.com/a/41336431

Of course, this needs to be done on every distros you have installed, as well as all systems you may SSH in to, and it might cause unexpected and unwanted behavior in other programs which use curses. I've heard it causes problems with Midnight Commander, for example. It's nuts that we have to do any of this, though.

@dziban303 commented on GitHub (Feb 5, 2024): This feature should be rolled back until a way to toggle it is arrived at. A line in the config file is fine, it doesn't need a bespoke UI element right away. And it should probably be disabled by default. Windows Terminal users have made it for years without it. I don't know how many users have been waiting for it to be implemented but I wager it's a smaller pool than that of people who need to use text editors. @jtabox The easiest workaround is here: https://stackoverflow.com/a/41336431 Of course, this needs to be done on every distros you have installed, as well as all systems you may SSH in to, and it might cause unexpected and unwanted behavior in other programs which use `curses`. I've heard it causes problems with Midnight Commander, for example. It's nuts that we have to do any of this, though.
claunia commented 2026-01-31 07:35:45 +00:00
Author
Owner
Copy Link

@jtabox commented on GitHub (Feb 5, 2024):

@dziban303 Yes, I checked that link but I'm a bit hesitant to modify the file it says, since it feels a bit too drastic and I'm really not in a mood of potentially creating more unexpected behaviors that I then have to try and fix. This has already taken 1+ hour until I could figure out why my numpad suddenly isn't working any more, and trying to fix it.

And as you say, I'd have to make this change to 3 local WSL distros and 2 remote ones. I had hoped there was an easy way to fix the binds in nano, same way I could with zsh but it seems there isn't any. For now I've stopped using the Preview version and gone back to version 1.19.

And true, it doesn't need to be an option in Windows Terminal's GUI, just an option in the config file or somewhere would be greatly appreciated.

But thanks for your reply regardless.

@jtabox commented on GitHub (Feb 5, 2024): @dziban303 Yes, I checked that link but I'm a bit hesitant to modify the file it says, since it feels a bit too drastic and I'm really not in a mood of potentially creating more unexpected behaviors that I then have to try and fix. This has already taken 1+ hour until I could figure out why my numpad suddenly isn't working any more, and trying to fix it. And as you say, I'd have to make this change to 3 local WSL distros and 2 remote ones. I had hoped there was an easy way to fix the binds in nano, same way I could with zsh but it seems there isn't any. For now I've stopped using the Preview version and gone back to version 1.19. And true, it doesn't need to be an option in Windows Terminal's GUI, just an option in the config file or somewhere would be greatly appreciated. But thanks for your reply regardless.
claunia commented 2026-01-31 07:35:45 +00:00
Author
Owner
Copy Link

@dziban303 commented on GitHub (Feb 5, 2024):

I understand, I was hesitant to do it as well. I couldn't figure it how to bind the keypad keys in nano either.

@dziban303 commented on GitHub (Feb 5, 2024): I understand, I was hesitant to do it as well. I couldn't figure it how to bind the keypad keys in nano either.
claunia commented 2026-01-31 07:35:46 +00:00
Author
Owner
Copy Link

@mveroone commented on GitHub (Feb 5, 2024):

@j4james as other stated, I think the most sensible action at this point would be to revert this change for now until you find a better approach. There likely are thousands of affected users here. It would also allow you to have time to look for a good solution without the pressure.

EDIT : apologies, I understood that this only affects the "preview" version of MS term which as any beta program actually guarantees this kind of issues might happen and must be bore with. I'm reverting to the stable version for now on my side.

@mveroone commented on GitHub (Feb 5, 2024): @j4james as other stated, I think the most sensible action at this point would be to revert this change for now until you find a better approach. ~There likely are thousands of affected users here. It would also allow you to have time to look for a good solution without the pressure.~ EDIT : apologies, I understood that this only affects the "preview" version of MS term which as any beta program actually guarantees this kind of issues might happen and must be bore with. I'm reverting to the stable version for now on my side.
claunia commented 2026-01-31 07:35:46 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 5, 2024):

@ MS Devs: For the record, I'd be happy for you to pull the DECKPAM mappings1 if you think that's best. I did look to see what other options we might have, and there is an XTerm mode that we could potentially use to toggle the functionality (mode ?1035), but it's not a simple on/off kind of thing, which makes it a bit of a pain to implement. So personally I don't think it's worth the effort, but we could possibly reconsider that later.

A couple of other points worth noting:

  • Technically DECKPAM is a VT conformance requirement, but I suspect I'm the only person that cares, and it could eventually be re-enabled via something like DECSCL, so I don't think that's a big deal.

  • It's needed to correctly map a number of keys in the xterm-256color terminfo definition (see ka1, ka3, kb2, kc1, kc3, and kent). That's not something that I care about, but other people might do.

  1. I'd suggest we just remove the ANSI mappings, but leave the VT52 ones. We may also need to nuke the defineNumericKey helper. ↩︎

@j4james commented on GitHub (Feb 5, 2024): @ MS Devs: For the record, I'd be happy for you to pull the `DECKPAM` mappings[^1] if you think that's best. I did look to see what other options we might have, and there is an XTerm mode that we could potentially use to toggle the functionality (mode ?1035), but it's not a simple on/off kind of thing, which makes it a bit of a pain to implement. So personally I don't think it's worth the effort, but we could possibly reconsider that later. A couple of other points worth noting: * Technically `DECKPAM` is a VT conformance requirement, but I suspect I'm the only person that cares, and it could eventually be re-enabled via something like `DECSCL`, so I don't think that's a big deal. * It's needed to correctly map a number of keys in the `xterm-256color` terminfo definition (see `ka1`, `ka3`, `kb2`, `kc1`, `kc3`, and `kent`). That's not something that I care about, but other people might do. [^1]: I'd suggest we just remove the [ANSI mappings](https://github.com/microsoft/terminal/blob/ef96e225da6b0df496390eed9fe31dc7e434a939/src/terminal/input/terminalInput.cpp#L440-L465), but leave the VT52 ones. We may also need to nuke the `defineNumericKey` helper.
claunia commented 2026-01-31 07:35:46 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 5, 2024):

For everyone participating in this thread: Thank you for bearing with us and reporting this issue!

And thank you, @j4james, for fielding all the comments over here and your eternal pursuit of VT conformance. 🙂

For right now, we're thinking that we should disable DECKPAM via velocity (keep the code, leave it on in the Dev build so that we can work on it.) I suppose that right now we're almost too compatible.

  • Disable DECKPAM (ANSI) with velocity; backport this to 1.20
  • Make it configurable on the Terminal side
    • Disable it in conhost until we figure out where to store settings for it
    • Invest in the ConPTY configuration API (Leonard keeps terrifyingly calling this ConPTY IOCTL) so that Terminal can tell the console to enable or disable it

EDIT : apologies ... beta program

@mveroone Thank you for adding that 😄

I'd also like to emphasize the "beta program" part! Thank you all for testing out the Preview channel so we can get some eyes our new stuff before we inflict it on a really mind-boggling amount of people.

@DHowett commented on GitHub (Feb 5, 2024): For everyone participating in this thread: Thank you for bearing with us and reporting this issue! And thank you, @j4james, for fielding all the comments over here and your eternal pursuit of VT conformance. 🙂 For right now, we're thinking that we should disable `DECKPAM` via velocity (keep the code, leave it on in the Dev build so that we can work on it.) I suppose that right now we're almost _too_ compatible. * Disable `DECKPAM` (ANSI) with velocity; backport this to 1.20 * Make it configurable on the Terminal side * Disable it in conhost until we figure out where to store settings for it * Invest in the ConPTY configuration API (Leonard keeps terrifyingly calling this ConPTY IOCTL) so that Terminal can _tell the console to enable or disable it_ > EDIT : apologies ... beta program @mveroone Thank you for adding that :smile: I'd also like to emphasize the "beta program" part! Thank you all for testing out the Preview channel so we can get some eyes our new stuff before we inflict it on a really mind-boggling amount of people.
claunia commented 2026-01-31 07:35:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 6, 2024):

(FWIW I'm gonna split this into two threads. This thread, we'll use for tracking disabling it broadly, and #16672 for re-enabling with a toggle)

@zadjii-msft commented on GitHub (Feb 6, 2024): (FWIW I'm gonna split this into two threads. This thread, we'll use for tracking disabling it broadly, and #16672 for re-enabling with a toggle)
claunia commented 2026-01-31 07:35:46 +00:00
Author
Owner
Copy Link

@jtabox commented on GitHub (Feb 6, 2024):

@j4james I want to apologize if my post above came off as bitter. I didn't mean to disrespect your work, and the fact you're allowing us to use it for free is greatly appreciated.

@jtabox commented on GitHub (Feb 6, 2024): @j4james I want to apologize if my post above came off as bitter. I didn't mean to disrespect your work, and the fact you're allowing us to use it for free is greatly appreciated.
claunia commented 2026-01-31 07:35:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 6, 2024):

Alas, I didn't have time to test this before the baby woke up this morning: dev/migrie/b/16654-disable-deckpam but that should disable it? At least, I think those are all the places these particular sequences are generated. @j4james sanity check?

@zadjii-msft commented on GitHub (Feb 6, 2024): Alas, I didn't have time to test this before the baby woke up this morning: [`dev/migrie/b/16654-disable-deckpam`](https://github.com/microsoft/terminal/compare/dev/migrie/b/16654-disable-deckpam) but that should disable it? At least, I think those are all the places these particular sequences are generated. @j4james sanity check?
claunia commented 2026-01-31 07:35:47 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 6, 2024):

@zadjii-msft I was saying you could probably still leave the VT52 ones active, but really it doesn't matter either way. It feels cleaner doing them both, so I think what you have is good.

@j4james commented on GitHub (Feb 6, 2024): @zadjii-msft I was saying you could probably still leave the VT52 ones active, but really it doesn't matter either way. It feels cleaner doing them both, so I think what you have is good.
claunia commented 2026-01-31 07:35:47 +00:00
Author
Owner
Copy Link

@timelmer-uw commented on GitHub (Feb 6, 2024):

This also breaks keypad input for Juniper Networks' JUNOS over SSH (csh).

@timelmer-uw commented on GitHub (Feb 6, 2024): This also breaks keypad input for Juniper Networks' JUNOS over SSH (csh).
claunia commented 2026-01-31 07:35:47 +00:00
Author
Owner
Copy Link

@oldium commented on GitHub (Feb 13, 2024):

FYI Midnight Commander (ncurses app) does not work with this - the numeric keypad cannot be switched to numbers in any way. Looking forward for next iteration 😁

@oldium commented on GitHub (Feb 13, 2024): FYI Midnight Commander (ncurses app) does not work with this - the numeric keypad cannot be switched to numbers in any way. Looking forward for next iteration 😁
claunia commented 2026-01-31 07:35:47 +00:00
Author
Owner
Copy Link

@michaelarnauts commented on GitHub (Feb 26, 2024):

Hi. I've started having this issue today too, and I was able to fix ZSH by adding this in my zshrc, however i still have an Issue with 3 & 9 acting as PgDown & PgUp in vim so there's something strange that changed.

# Fix numpad not working
# 0 . Enter
bindkey -s "^[Op" "0"
bindkey -s "^[Ol" "."
bindkey -s "^[OM" "^M"
# 1 2 3
bindkey -s "^[Oq" "1"
bindkey -s "^[Or" "2"
bindkey -s "^[Os" "3"
# 4 5 6
bindkey -s "^[Ot" "4"
bindkey -s "^[Ou" "5"
bindkey -s "^[Ov" "6"
# 7 8 9
bindkey -s "^[Ow" "7"
bindkey -s "^[Ox" "8"
bindkey -s "^[Oy" "9"
# + -  * /
bindkey -s "^[Ok" "+"
bindkey -s "^[Om" "-"
bindkey -s "^[Oj" "*"
bindkey -s "^[Oo" "/"

I had to use bindkey -s "^[On" "." for the dot to start working.

@michaelarnauts commented on GitHub (Feb 26, 2024): > Hi. I've started having this issue today too, and I was able to fix ZSH by adding this in my zshrc, however i still have an Issue with 3 & 9 acting as PgDown & PgUp in `vim` so there's something strange that changed. > > ``` > # Fix numpad not working > # 0 . Enter > bindkey -s "^[Op" "0" > bindkey -s "^[Ol" "." > bindkey -s "^[OM" "^M" > # 1 2 3 > bindkey -s "^[Oq" "1" > bindkey -s "^[Or" "2" > bindkey -s "^[Os" "3" > # 4 5 6 > bindkey -s "^[Ot" "4" > bindkey -s "^[Ou" "5" > bindkey -s "^[Ov" "6" > # 7 8 9 > bindkey -s "^[Ow" "7" > bindkey -s "^[Ox" "8" > bindkey -s "^[Oy" "9" > # + - * / > bindkey -s "^[Ok" "+" > bindkey -s "^[Om" "-" > bindkey -s "^[Oj" "*" > bindkey -s "^[Oo" "/" > ``` I had to use `bindkey -s "^[On" "."` for the dot to start working.
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 Area-VT In-PR Issue-Bug Needs-Tag-Fix Product-Conhost 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#21185
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?