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

Multiple compatibility issues with Google Japanese Input (IME) in vim with WSL #18108

New Issue
Closed
opened 2026-01-31 06:03:53 +00:00 by claunia · 14 comments
claunia commented 2026-01-31 06:03:53 +00:00
Owner
Copy Link

Originally created by @robqliu on GitHub (Aug 5, 2022).

Windows Terminal version

1.14.1962.0

Windows build number

10.0.19044.0

Other Software

$ vi --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08)
Included patches: 1-2434
Extra patches: 8.2.3402, 8.2.3403, 8.2.3409, 8.2.3428

inside WSL (debian)

Steps to reproduce

  1. Install Google Japanese Input IME
  2. Open up vim within Terminal and launch a WSL session (I'm on debian, but I doubt it matters?)
  3. Hit alt + shift and then observe the issues described below.

Expected Behavior

Sorry for combining multiple issues into one ticket. I can split it up if it helps.

  1. The first issue is that the normal hotkey for swapping to japanese input is not swapping to the last used "mode". For instance, Google Japanese Input has multiple modes (Hiragana, Full-width Katakana, Full-width alphanumeric, etc.). What I've observed is that alt + shift swaps between your most recently used IMEs and it preserves the mode in Google Japanese Input for me... unless I'm using Terminal, in which case it seems to always go to Half-width alphanumeric. It's worth noting that this is true even when I'm not in vim/when I'm just on the command line in bash.
  2. Related to (1), if I use alt + ` , it normally cycles through all of the "modes". When I'm in Terminal, it seems to only cycle between Half-width alphanumeric and Direct Input.
  3. Possibly related to the above issues, once I'm using Google Japanese Input, I expect it to swap between my usual mode, Hiragana, and Direct Input Mode when I swap modes in vim. For instance, I often am in Hiragana mode when I'm typing (i.e. Insert Mode in vim). When I want to navigate text, I swap to Normal mode in vim and it magically swaps to Direct Input as is necessary for moving around. As you can see in the gif, it stays in Hiragana mode.

For what it's worth, (1) matters a lot less than (2) or (3) since I can stay with the Google Japanese Input IME for the most part without issue. In particular, once I swap to Hiragana manually (or via ctrl + caps lock) then (2) actually stops being an issue? Or at least it lets me cycle between Hiragana and Direct Input which is what I care about. (3) is super annoying because I basically have to train different muscle memory when I use Terminal vs gvim or even git bash for windows.

Actual Behavior

As described above, I would like the behavior here to match other apps:

  1. alt + shift into Google Japanese Input should pick the most recently used "mode" in that IME
  2. alt + ` should cycle through all of the modes
  3. It should swap between the most recently used mode (e.g. Hiragana) and Direct Input when going between Insert mode and Normal mode in vim

bug

Originally created by @robqliu on GitHub (Aug 5, 2022). ### Windows Terminal version 1.14.1962.0 ### Windows build number 10.0.19044.0 ### Other Software $ vi --version VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08) Included patches: 1-2434 Extra patches: 8.2.3402, 8.2.3403, 8.2.3409, 8.2.3428 inside WSL (debian) ### Steps to reproduce 1. Install Google Japanese Input IME 2. Open up vim within Terminal and launch a WSL session (I'm on debian, but I doubt it matters?) 3. Hit `alt + shift` and then observe the issues described below. ### Expected Behavior Sorry for combining multiple issues into one ticket. I can split it up if it helps. 1. The first issue is that the normal hotkey for swapping to japanese input is not swapping to the last used "mode". For instance, Google Japanese Input has multiple modes (Hiragana, Full-width Katakana, Full-width alphanumeric, etc.). What I've observed is that `alt + shift` swaps between your most recently used IMEs and it preserves the mode in Google Japanese Input for me... unless I'm using Terminal, in which case it seems to always go to `Half-width alphanumeric`. It's worth noting that this is true even when I'm not in vim/when I'm just on the command line in bash. 2. Related to (1), if I use ``alt + ` ``, it normally cycles through all of the "modes". When I'm in Terminal, it seems to only cycle between `Half-width alphanumeric` and `Direct Input`. 3. Possibly related to the above issues, once I'm using Google Japanese Input, I expect it to swap between my usual mode, Hiragana, and Direct Input Mode when I swap modes in vim. For instance, I often am in Hiragana mode when I'm typing (i.e. Insert Mode in vim). When I want to navigate text, I swap to Normal mode in vim and it magically swaps to Direct Input as is necessary for moving around. As you can see in the gif, it stays in Hiragana mode. For what it's worth, (1) matters a lot less than (2) or (3) since I can stay with the Google Japanese Input IME for the most part without issue. In particular, once I swap to Hiragana manually (or via `ctrl + caps lock`) then (2) actually stops being an issue? Or at least it lets me cycle between Hiragana and Direct Input which is what I care about. (3) is super annoying because I basically have to train different muscle memory when I use Terminal vs gvim or even git bash for windows. ### Actual Behavior As described above, I would like the behavior here to match other apps: 1. `alt + shift` into Google Japanese Input should pick the most recently used "mode" in that IME 2. ``alt + ` `` should cycle through all of the modes 3. It should swap between the most recently used mode (e.g. Hiragana) and Direct Input when going between Insert mode and Normal mode in vim ![bug](https://user-images.githubusercontent.com/1217648/182991381-1cb72144-69c3-45fb-86bb-3287f78b29e8.gif)
claunia added the Needs-TriageIssue-BugArea-InputProduct-Terminal labels 2026-01-31 06:03:53 +00:00
claunia commented 2026-01-31 06:03:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 5, 2022):

@lhecker another related to #13398. Wanna just take a quick sanity pass on this IME too?

@zadjii-msft commented on GitHub (Aug 5, 2022): @lhecker another related to #13398. Wanna just take a quick sanity pass on this IME too?
claunia commented 2026-01-31 06:03:56 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 5, 2022):

I've just installed the IME and I'm already hitting a problem at reproducing the issue. 😥
Alt+Shift doesn't switch between the most recently used mode for me. Alt+` does.
Are you perhaps using any custom settings for Google Japanese Input or a different version? I'm on 2.28.4650.0. I couldn't find any setting that would change this behavior...

Edit (2022-08-15):
Sorry about my confusion in regards to Alt+Shift btw. I forgot that I disable it by default on my setups (so that it doesn't interfere with any shortcuts I configure - I use Win+Space instead which always works):
image

@lhecker commented on GitHub (Aug 5, 2022): I've just installed the IME and I'm already hitting a problem at reproducing the issue. 😥 Alt+Shift doesn't switch between the most recently used mode for me. Alt+` does. Are you perhaps using any custom settings for Google Japanese Input or a different version? I'm on 2.28.4650.0. I couldn't find any setting that would change this behavior... Edit (2022-08-15): Sorry about my confusion in regards to Alt+Shift btw. I forgot that I disable it by default on my setups (so that it doesn't interfere with any shortcuts I configure - I use Win+Space instead which always works): ![image](https://user-images.githubusercontent.com/2256941/184677985-63a89754-31f5-4d13-b5e6-2759487e385e.png)
claunia commented 2026-01-31 06:03:56 +00:00
Author
Owner
Copy Link

@ashemedai commented on GitHub (Aug 5, 2022):

On Windows 10: I can confirm 1. After pressing enter on the Japanese string, the IME resets to half-width input immediately. You do not even have to switch IMEs to trigger this.

For 2, my Alt+` switches between hiragana, or Japanese input, and half-width, or direct input. But it also does this in e.g. Notepad. AFAIK Alt+` isn't supposed to iterate through all modes. The shortcut documentation seems to agree here.

Edit addendum: I am dumb and totally missed this is about Google's IME, not Microsoft's. I tested with Microsoft's IME.

@ashemedai commented on GitHub (Aug 5, 2022): On Windows 10: I can confirm `1`. After pressing enter on the Japanese string, the IME resets to half-width input immediately. You do not even have to switch IMEs to trigger this. For `2`, my Alt+\` switches between hiragana, or Japanese input, and half-width, or direct input. But it also does this in e.g. Notepad. AFAIK Alt+\` isn't supposed to iterate through all modes. The [shortcut documentation seems to agree here](https://support.microsoft.com/en-us/windows/microsoft-japanese-ime-da40471d-6b91-4042-ae8b-713a96476916#bkmk_shortcuts&ID0EBBL=English_keyboard_(101/102_key)). Edit addendum: I am dumb and totally missed this is about Google's IME, not Microsoft's. I tested with Microsoft's IME.
claunia commented 2026-01-31 06:03:56 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 5, 2022):

On Windows 10: I can confirm 1. After pressing enter on the Japanese string, the IME resets to half-width input immediately. You do not even have to switch IMEs to trigger this.

I couldn't reproduce this with the Google Japanese Input IME - only with the Microsoft Japanese IME. But that issue will be fixed by #13678.

@lhecker commented on GitHub (Aug 5, 2022): > On Windows 10: I can confirm `1`. After pressing enter on the Japanese string, the IME resets to half-width input immediately. You do not even have to switch IMEs to trigger this. I couldn't reproduce this with the Google Japanese Input IME - only with the Microsoft Japanese IME. But that issue will be fixed by #13678.
claunia commented 2026-01-31 06:03:57 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 5, 2022):

  1. Possibly related to the above issues, once I'm using Google Japanese Input, I expect it to swap between my usual mode, Hiragana, and Direct Input Mode when I swap modes in vim. [...]

@robqliu I'm not 100% certain I understood you correctly, but I believe we can't fix that issue (point 3.), because a Terminal has no knowledge about what "kind" of input an application wants. In other words, vim doesn't tell the terminal when it enters or exits edit mode, so we can't switch between Hiragana/Direct input mode either.
But maybe the this works in gvim (i.e. the UI version of vim for Windows), since that one isn't actually running in a terminal? gvim has full control over how it wants input, so they could definitely support that feature.

@lhecker commented on GitHub (Aug 5, 2022): > 3. Possibly related to the above issues, once I'm using Google Japanese Input, I expect it to swap between my usual mode, Hiragana, and Direct Input Mode when I swap modes in vim. [...] @robqliu I'm not 100% certain I understood you correctly, but I believe we can't fix that issue (point 3.), because a Terminal has no knowledge about what "kind" of input an application wants. In other words, `vim` doesn't tell the terminal when it enters or exits edit mode, so we can't switch between Hiragana/Direct input mode either. But maybe the this works in `gvim` (i.e. the UI version of `vim` for Windows), since that one isn't actually running in a terminal? `gvim` has full control over how it wants input, so they could definitely support that feature.
claunia commented 2026-01-31 06:03:57 +00:00
Author
Owner
Copy Link

@ashemedai commented on GitHub (Aug 5, 2022):

On Windows 10: I can confirm 1. After pressing enter on the Japanese string, the IME resets to half-width input immediately. You do not even have to switch IMEs to trigger this.

I couldn't reproduce this with the Google Japanese Input IME - only with the Microsoft Japanese IME. But that issue will be fixed by #13678.

Sorry, it's been a long day. Totally missed this is about the Google Japanese IME, not the Microsoft one. Disregard my Alt+` comment then.

@ashemedai commented on GitHub (Aug 5, 2022): > > On Windows 10: I can confirm `1`. After pressing enter on the Japanese string, the IME resets to half-width input immediately. You do not even have to switch IMEs to trigger this. > > I couldn't reproduce this with the Google Japanese Input IME - only with the Microsoft Japanese IME. But that issue will be fixed by #13678. Sorry, it's been a long day. Totally missed this is about the Google Japanese IME, not the Microsoft one. Disregard my Alt+\` comment then.
claunia commented 2026-01-31 06:03:57 +00:00
Author
Owner
Copy Link

@robqliu commented on GitHub (Aug 5, 2022):

I've just installed the IME and I'm already hitting a problem at reproducing the issue. 😥 Alt+Shift doesn't switch between the most recently used mode for me. Alt+` does. Are you perhaps using any custom settings for Google Japanese Input or a different version? I'm on 2.28.4650.0. I couldn't find any setting that would change this behavior...

The alt+shift binding I learned when I was using the Microsoft Japanese IME. Here are some random links that mention it, I don't believe I ever manually added a binding (nor do I really see how...):
https://sethclydesdale.github.io/genki-study-resources/help/writing/#microsoft-shortcuts
https://answers.microsoft.com/en-us/windows/forum/all/japanese-ime-hiragana-toggle-keys/3b2ffa3e-29ee-4d5a-b65b-dc67c9c869fc

Yeah I've seen the point about gvim vs. vim in other tickets, but I think I'm just confused how git bash for windows seems to deal with this. It uses a specially compiled version of vim but shouldn't it have the same issues? Or do you think their vim is somehow integrated with the git bash terminal in a way that it can toggle the current IME? I can try swapping to gvim since I already have an x-server setup for other apps, but I've always had minor issues with gvim (probably just my configuration being not-actually-portable).

edit Hm, gvim seems to have other issues. I can swap to Hiragana via alt + ` , but it... doesn't actually work? Like I can't actually type hiragana/there's no pop-up window--it's identical to if the keyboard was still set to ENG. Also, it doesn't seem to swap IMEs based on input mode vs. normal mode. I wonder if this is just a configuration issue with gvim though...

@robqliu commented on GitHub (Aug 5, 2022): > I've just installed the IME and I'm already hitting a problem at reproducing the issue. 😥 Alt+Shift doesn't switch between the most recently used mode for me. Alt+` does. Are you perhaps using any custom settings for Google Japanese Input or a different version? I'm on 2.28.4650.0. I couldn't find any setting that would change this behavior... The alt+shift binding I learned when I was using the Microsoft Japanese IME. Here are some random links that mention it, I don't believe I ever manually added a binding (nor do I really see how...): https://sethclydesdale.github.io/genki-study-resources/help/writing/#microsoft-shortcuts https://answers.microsoft.com/en-us/windows/forum/all/japanese-ime-hiragana-toggle-keys/3b2ffa3e-29ee-4d5a-b65b-dc67c9c869fc Yeah I've seen the point about gvim vs. vim in other tickets, but I think I'm just confused how git bash for windows seems to deal with this. It uses a specially compiled version of vim but shouldn't it have the same issues? Or do you think their vim is somehow integrated with the git bash terminal in a way that it can toggle the current IME? I can try swapping to gvim since I already have an x-server setup for other apps, but I've always had minor issues with gvim (probably just my configuration being not-actually-portable). *edit* Hm, gvim seems to have other issues. I can swap to Hiragana via ``alt + ` ``, but it... doesn't actually work? Like I can't actually type hiragana/there's no pop-up window--it's identical to if the keyboard was still set to ENG. Also, it doesn't seem to swap IMEs based on input mode vs. normal mode. I wonder if this is just a configuration issue with gvim though...
claunia commented 2026-01-31 06:03:57 +00:00
Author
Owner
Copy Link

@yuru7 commented on GitHub (Aug 7, 2022):

I think alt+shift binding is a Windows settings.

The setting procedure is described in the following page. I apologize that it is in Japanese and is a help page of a computer manufacturer.
https://support.hp.com/jp-ja/document/c02652602

@yuru7 commented on GitHub (Aug 7, 2022): I think `alt+shift` binding is a Windows settings. The setting procedure is described in the following page. I apologize that it is in Japanese and is a help page of a computer manufacturer. https://support.hp.com/jp-ja/document/c02652602
claunia commented 2026-01-31 06:03:58 +00:00
Author
Owner
Copy Link

@driver1998 commented on GitHub (Aug 12, 2022):

Alt-Shift is a Windows shortcut to switch between input languages, not keyboard layouts or IMEs. So you'll need something like English language and Japanese Language with IMEs for it to work.

Ctrl-Shift is for switching keyboard layouts or IMEs within a language.

@driver1998 commented on GitHub (Aug 12, 2022): Alt-Shift is a Windows shortcut to switch between input __languages__, not keyboard layouts or IMEs. So you'll need something like English language and Japanese Language with IMEs for it to work. Ctrl-Shift is for switching keyboard layouts or IMEs __within a language__.
claunia commented 2026-01-31 06:03:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 15, 2022):

Sorry, there's a lot to try and unpack here. To try and summarize:

  1. "alt+shift should swap between your most recently used IMEs, and it preserves the mode in Google Japanese Input for me... unless I'm using Terminal, in which case it seems to always go to Half-width alphanumeric"
    • This sounds like it would be improved by #13678
  2. if I use alt + `, it normally cycles through all of the "modes". When I'm in Terminal, it seems to only cycle between Half-width alphanumeric and Direct Input
    • Same as above
  3. Yea, this sounds like something that gvim can do, but vim in the Terminal wouldn't be capable of (there's no way for a client app to tell it's connected terminal window to change the IME mode)

Right? Maybe we can get a hotfix build of 1.15 with that PR in it out soon to confirm?

@zadjii-msft commented on GitHub (Aug 15, 2022): Sorry, there's a lot to try and unpack here. To try and summarize: 1. "`alt+shift` should swap between your most recently used IMEs, and it preserves the mode in Google Japanese Input for me... unless I'm using Terminal, in which case it seems to always go to `Half-width alphanumeric`" - This sounds like it would be improved by #13678 2. if I use <kbd>alt + \`</kbd>, it normally cycles through all of the "modes". When I'm in Terminal, it seems to only cycle between `Half-width alphanumeric` and `Direct Input` - Same as above 3. Yea, this sounds like something that `gvim` can do, but `vim` in the Terminal wouldn't be capable of (there's no way for a client app to tell it's connected terminal window to change the IME mode) Right? Maybe we can get a hotfix build of 1.15 with that PR in it out soon to confirm?
claunia commented 2026-01-31 06:03:58 +00:00
Author
Owner
Copy Link

@robqliu commented on GitHub (Aug 15, 2022):

Hm, the issues linked to in that commit seem orthogonal, but the description of the fix feels vaguely generic enough that it might end up fixing (1) and (2)? Looking forward to trying out a build when it's available

For (3), I think I'm just curious why "git bash for windows" seems to support this if WSL can't. Like how is their version of vim "tell[ing] the terminal when it enters or exits edit mode"? But yeah, if it's truly impossible then that's how it is. Though it's worth noting that gvim doesn't seem to work well in WSL per my comment above, but I can file a separate ticket for that

@robqliu commented on GitHub (Aug 15, 2022): Hm, the issues linked to in that commit seem orthogonal, but the description of the fix feels vaguely generic enough that it might end up fixing (1) and (2)? Looking forward to trying out a build when it's available For (3), I think I'm just curious why "git bash for windows" seems to support this if WSL can't. Like how is their version of vim "tell[ing] the terminal when it enters or exits edit mode"? But yeah, if it's truly impossible then that's how it is. Though it's worth noting that gvim doesn't seem to work well in WSL per my comment above, but I can file a separate ticket for that
claunia commented 2026-01-31 06:03:59 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Apr 18, 2024):

We just published a major update to our IME implementation in the nightly Canary branch. It was rewritten from the ground up and has tons of improvements! If you're interested in trying it out, you can get it here: https://aka.ms/terminal-canary-installer
If you already have the Canary build installed, you can use this link to force an update.

If you encounter any issues or have any suggestions, or if you simply like/dislike the changes, please let us know! Thank you for bearing with us. 😊

@lhecker commented on GitHub (Apr 18, 2024): We just published a major update to our IME implementation in the nightly Canary branch. It was rewritten from the ground up and has tons of improvements! If you're interested in trying it out, you can get it here: https://aka.ms/terminal-canary-installer If you already have the Canary build installed, you can use this link to force an update. If you encounter any issues or have any suggestions, or if you simply like/dislike the changes, please let us know! Thank you for bearing with us. 😊
claunia commented 2026-01-31 06:03:59 +00:00
Author
Owner
Copy Link

@robqliu commented on GitHub (Apr 19, 2024):

The issue where I couldn't swap to "hiragana" was resolved months ago (I'm on 1.19.10302.0). That's like half of (2) in the original issue. But was also the most important thing I cared about. To be clear, these things still do not work, but I don't consider to be essential:

  1. alt + shift does not preserve the state of an IME. It always swaps to Direct Input for me in Terminal
  2. ``alt + ``` does not swap between all of the modes. It only swaps between Direct Input and Hiragana
    • I don't actually know how I was doing this before, but it appears to only swap between these two in all applications for me now.
  3. The IME mode does not automatically swap to Direct Input when I go to normal mode in vim. Similarly, it does not automatically swap to Hiragana mode when I go to insert mode

I don't remember which of these is supposedly possible or not for (vim on) Terminal to do, but just wanted to note that the most important part of this ticket is resolved for me.

@robqliu commented on GitHub (Apr 19, 2024): The issue where I couldn't swap to "hiragana" was resolved months ago (I'm on 1.19.10302.0). That's like half of (2) in the original issue. But was also the most important thing I cared about. To be clear, these things still do not work, but I don't consider to be essential: 1. `alt + shift` does not preserve the state of an IME. It always swaps to Direct Input for me in Terminal 2. ~~``alt + ``` does not swap between all of the modes. It only swaps between Direct Input and Hiragana~~ - I don't actually know how I was doing this before, but it appears to only swap between these two in all applications for me now. 3. The IME mode does not automatically swap to Direct Input when I go to normal mode in vim. Similarly, it does not automatically swap to Hiragana mode when I go to insert mode I don't remember which of these is supposedly possible or not for (vim on) Terminal to do, but just wanted to note that the most important part of this ticket is resolved for me.
claunia commented 2026-01-31 06:03:59 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (May 8, 2024):

Thanks for working with us. The first one is fixed in 1.21 (at least as best as it can be). And the third one is inherently impossible. Closing as fixed 😊

@carlos-zamora commented on GitHub (May 8, 2024): Thanks for working with us. The first one is fixed in 1.21 (at least as best as it can be). And the third one is inherently impossible. Closing as fixed 😊
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 Issue-Bug Needs-Triage 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#18108
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?