starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 08:24:54 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Vim background color renders incorrectly #1137

New Issue
Closed
opened 2026-01-30 22:17:20 +00:00 by claunia · 16 comments
claunia commented 2026-01-30 22:17:20 +00:00
Owner
Copy Link

Originally created by @caksoylar on GitHub (May 15, 2019).

Originally assigned to: @zadjii-msft on GitHub.

  • Your Windows build number: (Type ver at a Windows Command Prompt)
    Microsoft Windows [Version 10.0.18362.86]

  • What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
    In conhost or Windows Terminal, using both Vim.exe and WSL Vim, background color rendering becomes broken if a background color >16 or true colors is used.

With an example file, e.g. https://github.com/GilbertsHub/web-utils/blob/master/cgibinIntercept.sh:

vim -u NONE cgibinIntercept.sh +"hi Normal ctermbg=17" # for Windows: +"set t_Co=256"
# scroll down with CTRL-D

In general it is much easier to reproduce in WSL than Vim.exe, because it doesn't seem to occur after the initial scroll on Vim.exe and the effects are a bit different as described below. I can reproduce with any combination of conhost/terminal and Vim 8.1.883 on Ubuntu/8.0 on Debian/8.1 on Win32. Does not reproduce with neovim (v0.4.0-430-g8698830cb).

A few cases of example behavior:

  • Debian with conhost, Vim from official repository
$ sudo apt install vim
$ vim --version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep 30 2017 18:21:38)
Included patches: 1-197, 322, 377-378, 550, 703, 706-707

vim-bg
Same behavior in the new terminal.

  • What's wrong / what should be happening instead:
    Background rendered the whole width of the window, e.g. in wsltty:
    vim-bg-wsltty

The effect is very similar to the issue https://github.com/microsoft/terminal/issues/375, however that one happens with bg color set to <16 (darkBlue). However I cannot reproduce that issue anymore, including the terminal bg change.

The issues for Win32 and Linux versions might be separate, since their effects are pretty different as described above.

I also haven't been able to reproduce this using VT sequences, but I hope the bug report is still useful.

Originally created by @caksoylar on GitHub (May 15, 2019). Originally assigned to: @zadjii-msft on GitHub. * Your Windows build number: (Type `ver` at a Windows Command Prompt) Microsoft Windows [Version 10.0.18362.86] * What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots) In conhost or Windows Terminal, using both Vim.exe and WSL Vim, background color rendering becomes broken if a background color >16 or true colors is used. With an example file, e.g. https://github.com/GilbertsHub/web-utils/blob/master/cgibinIntercept.sh: ```bash vim -u NONE cgibinIntercept.sh +"hi Normal ctermbg=17" # for Windows: +"set t_Co=256" # scroll down with CTRL-D ``` In general it is much easier to reproduce in WSL than Vim.exe, because it doesn't seem to occur after the initial scroll on Vim.exe and the effects are a bit different as described below. I can reproduce with any combination of conhost/terminal and Vim 8.1.883 on Ubuntu/8.0 on Debian/8.1 on Win32. Does not reproduce with neovim (v0.4.0-430-g8698830cb). A few cases of example behavior: - Debian with conhost, Vim from official repository ```bash $ sudo apt install vim $ vim --version VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep 30 2017 18:21:38) Included patches: 1-197, 322, 377-378, 550, 703, 706-707 ``` ![vim-bg](https://user-images.githubusercontent.com/7876996/57801234-26729d00-7708-11e9-8006-c1adc1bbbbcf.png) Same behavior in the new terminal. - Vim.exe on conhost cmd.exe installed from https://github.com/vim/vim-win32-installer/releases/download/v8.1.1099/gvim_8.1.1099_x64.exe ![vim-bg-conhost](https://user-images.githubusercontent.com/7876996/57803566-959ec000-770d-11e9-8c95-8a0ee6c13ef8.png) Background color is wrong on the text part but correct otherwise (purple, although this seems to depend on active colorscheme) but is fixed after a Ctrl-L redraw. - Vim.exe on Terminal cmd.exe, same as above ![vim-bg-terminal](https://user-images.githubusercontent.com/7876996/57802546-13ad9780-770b-11e9-88c6-1cba57e4fa9d.png) Background color is again wrong, but the background highlight completely disappears after a Ctrl-L redraw. * What's wrong / what should be happening instead: Background rendered the whole width of the window, e.g. in wsltty: ![vim-bg-wsltty](https://user-images.githubusercontent.com/7876996/57802542-101a1080-770b-11e9-93dd-338d8410e04f.png) The effect is very similar to the issue https://github.com/microsoft/terminal/issues/375, however that one happens with bg color set to <16 (`darkBlue`). However I cannot reproduce that issue anymore, including the terminal bg change. The issues for Win32 and Linux versions might be separate, since their effects are pretty different as described above. I also haven't been able to reproduce this using VT sequences, but I hope the bug report is still useful.
claunia commented 2026-01-30 22:17:21 +00:00
Author
Owner
Copy Link

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

The common fix is to disable Vim's "Background Color Erase (BCE)" option by setting t_ut to an empty string, like this:

:set t_ut=""
(then CTRL-L to re-draw)

This tells Vim to erase areas of the screen, as it does when back-scrolling, using the current background color (from the Vim color scheme) instead of relying on that specific Terminal's implementation of Background Color Erase (BCE) mode. Otherwise, areas are simply erased without regard for background color, which means the Terminal's DEFAULT background value would be used.

@xtremeperf commented on GitHub (May 19, 2019): The common fix is to disable Vim's "Background Color Erase (BCE)" option by setting t_ut to an empty string, like this: :set t_ut="" (then CTRL-L to re-draw) This tells Vim to erase areas of the screen, as it does when back-scrolling, using the current background color (from the Vim color scheme) instead of relying on that specific Terminal's implementation of Background Color Erase (BCE) mode. Otherwise, areas are simply erased without regard for background color, which means the Terminal's DEFAULT background value would be used.
claunia commented 2026-01-30 22:17:22 +00:00
Author
Owner
Copy Link

@caksoylar commented on GitHub (May 30, 2019):

Thanks for the pointer @xtremeperf, that does work around the issue. Although I still see flashes of the wrong background color during scrolling with something like vim-smooth-scroll which scrolls line-by-line rapidly.

As I understand it, Vim expects the terminal to support BCE (thus setting t_ut=y) when it reports itself as xterm-256color, but the terminal does not support it. Interestingly this implies that it might be an issue that was fixed before. Another possibly related issue I found is #70.

@caksoylar commented on GitHub (May 30, 2019): Thanks for the pointer @xtremeperf, that does work around the issue. Although I still see flashes of the wrong background color during scrolling with something like [vim-smooth-scroll](https://github.com/terryma/vim-smooth-scroll) which scrolls line-by-line rapidly. As I understand it, Vim expects the terminal to support BCE (thus setting `t_ut=y`) when it reports itself as `xterm-256color`, but the terminal does not support it. Interestingly [this](https://github.com/Microsoft/WSL/issues/1706#issuecomment-308570429) implies that it might be an issue that was fixed before. Another possibly related issue I found is #70.
claunia commented 2026-01-30 22:17:22 +00:00
Author
Owner
Copy Link

@xtremeperf commented on GitHub (Jun 16, 2019):

Exactly. Well, it can also happen if t_Co=256 and/or term=xterm

Also, to prevent those flashes of the wrong bg color during rapid scrolling when bce mode is disabled, you'll want to additionally configure the maximum number of lines that vim will scroll before redrawing the screen. Set it to 1 line. The following works well placed in a vimrc file:

if (&term =~ '^xterm' && &t_Co == 256)
  set t_ut= | set ttyscroll=1
endif

I'm think Microsoft/WSL #1706 was maybe an end-of-line/newline erase bug or something like that, but Microsoft/Terminal #70 sounds like the same Vim bce issue we're discussing here.

@xtremeperf commented on GitHub (Jun 16, 2019): Exactly. Well, it can also happen if `t_Co=256` and/or `term=xterm` Also, to prevent those flashes of the wrong bg color during rapid scrolling when bce mode is disabled, you'll want to additionally configure the maximum number of lines that vim will scroll before redrawing the screen. Set it to 1 line. The following works well placed in a vimrc file: ``` if (&term =~ '^xterm' && &t_Co == 256) set t_ut= | set ttyscroll=1 endif ``` I'm think Microsoft/WSL [#1706](https://github.com/Microsoft/WSL/issues/1706#issuecomment-308570429) was maybe an end-of-line/newline erase bug or something like that, but Microsoft/Terminal [#70](https://github.com/microsoft/terminal/issues/70) sounds like the same Vim bce issue we're discussing here.
claunia commented 2026-01-30 22:17:22 +00:00
Author
Owner
Copy Link

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

On Windows 10 1903 (18362.175) with WSL Ubuntu 18.04, the @xtremeperf workarounds involving set t_ut did not work for me. I found another workaround in an answer to a stack overflow question.
In ~/.vimrc put:

highlight Normal ctermfg=black ctermbg=lightgrey

When in vim, this sets the text color to black and the background color to lightgrey. Other colors are listed in /usr/share/vim/vim80/rgb.txt Not all those colors are supported on a 256 color xterm.

@brentpfister commented on GitHub (Jun 24, 2019): On Windows 10 1903 (18362.175) with WSL Ubuntu 18.04, the @xtremeperf workarounds involving `set t_ut` did not work for me. I found another workaround in an answer to a [stack overflow question](https://stackoverflow.com/questions/1117526/setting-the-vim-background-colors). In ~/.vimrc put: ``` highlight Normal ctermfg=black ctermbg=lightgrey ``` When in vim, this sets the text color to black and the background color to lightgrey. Other colors are listed in /usr/share/vim/vim80/rgb.txt Not all those colors are supported on a 256 color xterm.
claunia commented 2026-01-30 22:17:23 +00:00
Author
Owner
Copy Link

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

Note that you are setting the background to color 7 (and not to a true-color or 16-256 terminal colors) using lightgrey, which you can see in :help cterm-colors in Vim. As I noted above, this problem only occurs if the background color is set to either >=16 or an RGB value.

@caksoylar commented on GitHub (Jun 24, 2019): Note that you are setting the background to color `7` (and not to a true-color or 16-256 terminal colors) using `lightgrey`, which you can see in `:help cterm-colors` in Vim. As I noted above, this problem only occurs if the background color is set to either `>=16` or an RGB value.
claunia commented 2026-01-30 22:17:23 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jul 1, 2019):

This looks very similar to issue #70 - might be a duplicate. What is happening when you scroll, is you get a delete lines (DL) or insert lines (IL) escape sequence, which should fill the new space with the current background color, but it doesn't work correctly when using colors from the 256-color palette or RGB mode. A simple test case would be something like this:

printf "\ec\e[1;10r\e[H\e[48;5;2m\e[10M\nBG COLOR\e[r\e[m"

That sets a scroll region of 10 lines, and then erases those 10 lines with a green background color from the 256-color palette. While the BG COLOR text shows what the color should have been, the background is actually filled with black. If you replace the \e[48;5;2m sequence with the simpler 16-color sequence \e[42m it'll work.

printf "\ec\e[1;10r\e[H\e[42m\e[10M\nBG COLOR\e[r\e[m"

The reason for the failure can be found in the DoSrvPrivateModifyLinesImpl method, which calls the ScrollConsoleScreenBufferWImpl method to handle the scrolling. The latter only accepts legacy 16-color attributes, so it tries to derive an appropriate value using the TextAttribute::GetLegacyAttributes method. Unfortunately that method is essentially useless for anything that isn't already a legacy color.

That said, the ScrollConsoleScreenBufferWImpl does try to make up for the limitations of the API, and map the 16-color attributes back to their original RGB values. It does this by comparing the legacy value against the legacy equivalent of the current colors - if they match then it will use the full RGB values of the current colors. Unfortunately this doesn't work because it uses a different calculation for the legacy attributes (the Settings::GenerateLegacyAttributes method).

Assuming the ScrollConsoleScreenBufferWImpl can't be updated to handle full RGB attributes, the next best thing would be to use a better legacy attribute calculation in the DoSrvPrivateModifyLinesImpl method. If we were to use the same Settings::GenerateLegacyAttributes on both ends then the mapping back to RGB should work correctly. And in the event it can't map, because it really doesn't match the current color, then it should at least give a better approximation of the requested color.

@j4james commented on GitHub (Jul 1, 2019): This looks very similar to issue #70 - might be a duplicate. What is happening when you scroll, is you get a delete lines (DL) or insert lines (IL) escape sequence, which should fill the new space with the current background color, but it doesn't work correctly when using colors from the 256-color palette or RGB mode. A simple test case would be something like this: printf "\ec\e[1;10r\e[H\e[48;5;2m\e[10M\nBG COLOR\e[r\e[m" That sets a scroll region of 10 lines, and then erases those 10 lines with a green background color from the 256-color palette. While the `BG COLOR` text shows what the color should have been, the background is actually filled with black. If you replace the `\e[48;5;2m` sequence with the simpler 16-color sequence `\e[42m` it'll work. printf "\ec\e[1;10r\e[H\e[42m\e[10M\nBG COLOR\e[r\e[m" The reason for the failure can be found in the `DoSrvPrivateModifyLinesImpl` method, which calls the `ScrollConsoleScreenBufferWImpl` method to handle the scrolling. The latter only accepts legacy 16-color attributes, so it tries to derive an appropriate value using the `TextAttribute::GetLegacyAttributes` method. Unfortunately that method is essentially useless for anything that isn't already a legacy color. That said, the `ScrollConsoleScreenBufferWImpl` does try to make up for the limitations of the API, and map the 16-color attributes back to their original RGB values. It does this by comparing the legacy value against the legacy equivalent of the current colors - if they match then it will use the full RGB values of the current colors. Unfortunately this doesn't work because it uses a different calculation for the legacy attributes (the `Settings::GenerateLegacyAttributes` method). Assuming the `ScrollConsoleScreenBufferWImpl` can't be updated to handle full RGB attributes, the next best thing would be to use a better legacy attribute calculation in the `DoSrvPrivateModifyLinesImpl` method. If we were to use the same `Settings::GenerateLegacyAttributes` on both ends then the mapping back to RGB should work correctly. And in the event it can't map, because it really doesn't match the current color, then it should at least give a better approximation of the requested color.
claunia commented 2026-01-30 22:17:23 +00:00
Author
Owner
Copy Link

@kshji commented on GitHub (Aug 5, 2019):

I installed Windows Terminal 0.3 from Store and start bash shell using default profile wsl.exe -d Ubuntu-18.04 , no problem using color schema One Half Light which is reverse setup.

If I setup CMD reverse (fg 242, bg 12) and start wsl.exe -d Ubuntu-18.04 , no problem.

But when you set app Ubuntu 18.04 Ubuntu window/command properties same values, vim insert mode add black background.

@kshji commented on GitHub (Aug 5, 2019): I installed Windows Terminal 0.3 from Store and start bash shell using default profile `wsl.exe -d Ubuntu-18.04` , no problem using color schema **One Half Light** which is reverse setup. If I setup CMD reverse (fg 242, bg 12) and start `wsl.exe -d Ubuntu-18.04` , no problem. But when you set app Ubuntu 18.04 Ubuntu window/command properties same values, vim insert mode add black background.
claunia commented 2026-01-30 22:17:23 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 24, 2019):

:tada:This issue was addressed in #2668, which has now been successfully released as Windows Terminal Preview v0.5.2661.0.🎉

Handy links:

@ghost commented on GitHub (Sep 24, 2019): :tada:This issue was addressed in #2668, which has now been successfully released as `Windows Terminal Preview v0.5.2661.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.5.2661.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 22:17:24 +00:00
Author
Owner
Copy Link

@kazucmpt commented on GitHub (Aug 18, 2020):

Also, to prevent those flashes of the wrong bg color during rapid scrolling when bce mode is disabled, you'll want to additionally configure the maximum number of lines that vim will scroll before redrawing the screen. Set it to 1 line. The following works well placed in a vimrc file:

if (&term =~ '^xterm' && &t_Co == 256)
  set t_ut= | set ttyscroll=1
endif

I'm think Microsoft/WSL #1706 was maybe an end-of-line/newline erase bug or something like that, but Microsoft/Terminal #70 sounds like the same Vim bce issue we're discussing here.

Thanks to @xtremeperf, those flashes has been disappeared by adding

if (&term =~ '^xterm' && &t_Co == 256)
   set t_ut= | set ttyscroll=1
endif

on .vimrc.

But when I use vim on tmux, the flashes are appeard again.

Does somebody know how should I fix it?

@kazucmpt commented on GitHub (Aug 18, 2020): > Also, to prevent those flashes of the wrong bg color during rapid scrolling when bce mode is disabled, you'll want to additionally configure the maximum number of lines that vim will scroll before redrawing the screen. Set it to 1 line. The following works well placed in a vimrc file: > > ``` > if (&term =~ '^xterm' && &t_Co == 256) > set t_ut= | set ttyscroll=1 > endif > ``` > > I'm think Microsoft/WSL [#1706](https://github.com/Microsoft/WSL/issues/1706#issuecomment-308570429) was maybe an end-of-line/newline erase bug or something like that, but Microsoft/Terminal [#70](https://github.com/microsoft/terminal/issues/70) sounds like the same Vim bce issue we're discussing here. Thanks to @xtremeperf, those flashes has been disappeared by adding ``` if (&term =~ '^xterm' && &t_Co == 256) set t_ut= | set ttyscroll=1 endif ``` on .vimrc. But when I use vim on tmux, the flashes are appeard again. Does somebody know how should I fix it?
claunia commented 2026-01-30 22:17:24 +00:00
Author
Owner
Copy Link

@jasper-zanjani commented on GitHub (Aug 30, 2020):

I am experiencing similar issues using vim in Windows Terminal 1.2.2381.0.
As you can see, guifg and guibg are set to NONE, but the background is being painted black. This is definitely not Windows Terminal's background color, which was explicitly set to match the chosen vim theme.
image
Notably, this problem appears to be specific to Windows and does not occur in WSL:
image

@jasper-zanjani commented on GitHub (Aug 30, 2020): I am experiencing similar issues using vim in Windows Terminal 1.2.2381.0. As you can see, `guifg` and `guibg` are set to `NONE`, but the background is being painted black. This is definitely not Windows Terminal's background color, which was explicitly set to match the chosen vim theme. ![image](https://user-images.githubusercontent.com/8889926/91667527-3ec02400-ead3-11ea-8541-5b4b51b1aac0.png) Notably, this problem appears to be specific to Windows and does not occur in WSL: ![image](https://user-images.githubusercontent.com/8889926/91667551-834bbf80-ead3-11ea-8416-03acc25d730a.png)
claunia commented 2026-01-30 22:17:24 +00:00
Author
Owner
Copy Link

@leftbones commented on GitHub (Sep 25, 2021):

This issue should be reopened as it is NOT resolved.

@leftbones commented on GitHub (Sep 25, 2021): This issue should be reopened as it is NOT resolved.
claunia commented 2026-01-30 22:17:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 27, 2021):

@evprkr This was a pretty specific issue with a specific root cause back in 2019. If you're seeing something similar, then the best thing to do would be to open a new issue so we can help diagnose the (new) issue you're seeing.

@zadjii-msft commented on GitHub (Sep 27, 2021): @evprkr This was a pretty specific issue with a specific root cause back in 2019. If you're seeing something similar, then the best thing to do would be to open a new issue so we can help diagnose the (new) issue you're seeing.
claunia commented 2026-01-30 22:17:25 +00:00
Author
Owner
Copy Link

@zeroxia commented on GitHub (Aug 26, 2022):

The issue is still present with my setup:

Terminal

Windows Terminal Preview Version: 1.15.2002.0

Windows

Windows 10:
Microsoft Windows [Version 10.0.19044.1826]

Screenshots

Windows VIM version:

Windows VIM

OneDark color theme:
OneDark color theme

GruvBox color theme:
GruvBox color theme

@zeroxia commented on GitHub (Aug 26, 2022): The issue is still present with my setup: ## Terminal `Windows Terminal Preview Version: 1.15.2002.0` ## Windows Windows 10: `Microsoft Windows [Version 10.0.19044.1826]` ## Screenshots Windows VIM version: ![Windows VIM](http://tva1.sinaimg.cn/large/61260048gy1h5k8x5nl8kj20tf0m17jp.jpg) OneDark color theme: ![OneDark color theme](http://tva1.sinaimg.cn/large/61260048gy1h5k8xukhp0j20tf0m10wf.jpg) GruvBox color theme: ![GruvBox color theme](http://tva1.sinaimg.cn/large/61260048gy1h5k8ydcah3j20tf0m1jvf.jpg)
claunia commented 2026-01-30 22:17:25 +00:00
Author
Owner
Copy Link

@dibotak commented on GitHub (Sep 5, 2022):

https://vi.stackexchange.com/questions/17464/24-bit-256-colorscheme-in-windows-console
add this line set termguicolors to .vimrc worked for me

@dibotak commented on GitHub (Sep 5, 2022): https://vi.stackexchange.com/questions/17464/24-bit-256-colorscheme-in-windows-console add this line `set termguicolors` to .vimrc worked for me
claunia commented 2026-01-30 22:17:25 +00:00
Author
Owner
Copy Link

@zeroxia commented on GitHub (Sep 6, 2022):

termguicolors seems no effect for me, I put the following chunk to .vimrc for solving two issues concerning Terminal and vim:

if &term == 'win32'
    "" https://github.com/microsoft/terminal/issues/4335
    let &t_SI="\<CSI>5\ q"
    let &t_SR="\<CSI>7\ q"
    "let &t_EI="\<CSI>2\ q"
    "" https://github.com/microsoft/terminal/issues/832
    set t_ut= | set ttyscroll=1
endif
@zeroxia commented on GitHub (Sep 6, 2022): > `termguicolors` seems no effect for me, I put the following chunk to `.vimrc` for solving two issues concerning Terminal and vim: ```vim if &term == 'win32' "" https://github.com/microsoft/terminal/issues/4335 let &t_SI="\<CSI>5\ q" let &t_SR="\<CSI>7\ q" "let &t_EI="\<CSI>2\ q" "" https://github.com/microsoft/terminal/issues/832 set t_ut= | set ttyscroll=1 endif ```
claunia commented 2026-01-30 22:17:25 +00:00
Author
Owner
Copy Link

@gosukiwi commented on GitHub (Sep 25, 2022):

https://vi.stackexchange.com/questions/17464/24-bit-256-colorscheme-in-windows-console add this line set termguicolors to .vimrc worked for me

I had to find out about this the bad way :) It worked for me too!

@gosukiwi commented on GitHub (Sep 25, 2022): > https://vi.stackexchange.com/questions/17464/24-bit-256-colorscheme-in-windows-console add this line `set termguicolors` to .vimrc worked for me I had to find out about this the bad way :) It worked for me too!
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-VT Issue-Bug Priority-2 Product-Conhost Product-Terminal Resolution-Fix-Committed
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#1137
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?