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

Vim background colors are incorrectly drawn when scrolling #6914

New Issue
Closed
opened 2026-01-31 00:50:22 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 00:50:22 +00:00
Owner
Copy Link

Originally created by @idbrii on GitHub (Mar 17, 2020).

When scrolling in vim using a colorscheme that uses 256 colors and has colored backgrounds, some parts of the background are drawn an incorrect color.

Posting a new issue as requested on #70:

This would be a great issue for @Kayla Cinnamonmailto:Kayla.Cinnamon@microsoft.com & team to explore. Thanks for filing David.
since this issue is closed and you seem to be having some slightly different symptoms, would you mind filling a new one so that we might track it appropriately? Thanks.

Environment

I'm on Windows 1909 (OS Build 18363.657). (Public version, not insider.)

Using WSL: Ubuntu 14.04.5 LTS

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:43:18)
Included patches: 1-52
Extra patches: 8.0.0056

&term == xterm-256color
&t_Co == 256

Running a terminal as bash.exe ("Microsoft Bash Launcher")

Steps to reproduce

I can reproduce this with a minimal vim (so it's not using most of the details of my configuration -- the -u NONE flag ignores my config):

vim -Nu NONE +"colorscheme jellybeans" +"help help"

scroll around inside the help window.

Expected behavior

The background is dark grey.

Actual behavior

Some parts of the background (on the right-hand side) are green instead of dark grey.

Details

Where jellybeans is this specific version. (Also occurs with zellner, xoria256, sandydune, etc. but couldn't repro with any colors shipped with vim7. Probably because vim7 doesn't ship with schemes using 256 colors.)

Strangely, I only noticed this recently. Maybe after my Windows Update on 6-Mar-2020?

Either of these vim configuration settings will make the problem go away, but at the cost of reduced colours:

set term=xterm
set t_Co=16

I'm using the bash.exe that came with installing WSL through the Windows Store (2 years ago). I'm not using "Windows Terminal (Preview)" from the Windows Store (testing that, the issue doesn't occur because &term is win32 and &t_Co is 16 -- so it doesn't support 256 colours).

I ran this color test and thought it matched the screenshot, but I'll give it another go.

Sorry for not adding more details. I temporarily don't have access to the machine that was exhibiting this problem. When I regain access, I'll add more details to this report.

Originally created by @idbrii on GitHub (Mar 17, 2020). When scrolling in vim using a colorscheme that uses 256 colors and has colored backgrounds, some parts of the background are drawn an incorrect color. Posting a new issue as requested on #70: > This would be a great issue for @Kayla Cinnamon<mailto:Kayla.Cinnamon@microsoft.com> & team to explore. Thanks for filing David. > since this issue is closed and you seem to be having some slightly different symptoms, would you mind filling a new one so that we might track it appropriately? Thanks. # Environment I'm on Windows 1909 (OS Build 18363.657). (Public version, not insider.) Using WSL: Ubuntu 14.04.5 LTS VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:43:18) Included patches: 1-52 Extra patches: 8.0.0056 &term == xterm-256color &t_Co == 256 Running a terminal as bash.exe ("Microsoft Bash Launcher") <!-- ```none Windows build number: > [Environment]::OSVersion TODO Windows Terminal version (if applicable): not applicable? Linux version: $ lsb_release -a ``` --> # Steps to reproduce I can reproduce this with a minimal vim (so it's not using most of the details of my configuration -- the `-u NONE` flag ignores my config): ```sh vim -Nu NONE +"colorscheme jellybeans" +"help help" ``` scroll around inside the help window. # Expected behavior The background is dark grey. # Actual behavior Some parts of the background (on the right-hand side) are green instead of dark grey. <!--~ TODO: screenshot --> # Details Where [jellybeans is this specific version](https://github.com/idbrii/daveconfig/blob/3d03c751a6af0908191170e4a791016daedd1590/multi/vim/colors/jellybeans.vim). (Also occurs with zellner, xoria256, sandydune, etc. but couldn't repro with any colors shipped with vim7. Probably because vim7 doesn't ship with schemes using 256 colors.) Strangely, I only noticed this recently. Maybe after my Windows Update on 6-Mar-2020? Either of these vim configuration settings will make the problem go away, but at the cost of reduced colours: ```vim set term=xterm set t_Co=16 ``` I'm using the bash.exe that came with installing WSL through the Windows Store (2 years ago). I'm not using "Windows Terminal (Preview)" from the Windows Store (testing that, the issue doesn't occur because &term is win32 and &t_Co is 16 -- so it doesn't support 256 colours). I ran [this color test](https://github.com/microsoft/terminal/issues/70#issuecomment-366113395) and thought it matched the screenshot, but I'll give it another go. Sorry for not adding more details. I temporarily don't have access to the machine that was exhibiting this problem. When I regain access, I'll add more details to this report.
claunia added the Resolution-Duplicate label 2026-01-31 00:50:22 +00:00
claunia commented 2026-01-31 00:50:22 +00:00
Author
Owner
Copy Link

@idbrii commented on GitHub (Mar 17, 2020):

I setup a new workstation and was able to reproduce -- but not as drastic. Possibly this is a different issue.

With the new workstation, I can only repro on a different colorscheme. For some reason jellybeans doesn't give me problems (but also it doesn't look like it's using the correct colors).

Environment

> [Environment]::OSVersion
Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.17763.0 Microsoft Windows NT 10.0.17763.0


$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.4 LTS
Release:        18.04
Codename:       bionic


$ vim --version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jun 06 2019 17:31:41)
Included patches: 1-1453

In vim, I still see 256-color support:

&term == xterm-256color
&t_Co == 256

Steps to reproduce

vim -Nu NONE +"colorscheme zenburn" +"help help"

scroll down (Ctrl-d) inside the help window.

Expected behavior

The background is grey.

Actual behavior

Some parts of the background (on the right-hand side) are black instead of grey.

image

Details

Where zenburn is this specific version. (Several colorschemes that had this problem before now just have black backgrounds and don't have problems: jellybeans, zellner, xoria256, sandydune.)

From vim, I can issue :redraw! and the background looks correct. (The ! makes the screen get cleared first and without that, it doesn't draw the background correctly.)

Either of these vim configuration settings will make the problem go away, but at the cost of reduced colours:

set term=xterm
set t_Co=16

I'm using the bash.exe that came with installing WSL (Ubuntu -- the one that keeps updating to the latest LTS).

I ran this color test here's the output:

image

When I resize the window, all color lines become painted to the end. I guess that's equivalent to issuing a redraw from vim?

@idbrii commented on GitHub (Mar 17, 2020): I setup a new workstation and was able to reproduce -- but not as drastic. Possibly this is a different issue. With the new workstation, I can only repro on a different colorscheme. For some reason jellybeans doesn't give me problems (but also it doesn't look like it's using the correct colors). # Environment ```none > [Environment]::OSVersion Platform ServicePack Version VersionString -------- ----------- ------- ------------- Win32NT 10.0.17763.0 Microsoft Windows NT 10.0.17763.0 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.4 LTS Release: 18.04 Codename: bionic $ vim --version VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jun 06 2019 17:31:41) Included patches: 1-1453 ``` In vim, I still see 256-color support: ``` &term == xterm-256color &t_Co == 256 ``` # Steps to reproduce ```sh vim -Nu NONE +"colorscheme zenburn" +"help help" ``` scroll down (Ctrl-d) inside the help window. # Expected behavior The background is grey. # Actual behavior Some parts of the background (on the right-hand side) are black instead of grey. ![image](https://user-images.githubusercontent.com/43559/76811848-494e6180-67b0-11ea-9f83-2e21fbaaa0b6.png) # Details Where [zenburn is this specific version](https://github.com/idbrii/daveconfig/blob/d93c00acc1dfb96c847adc927a6ecd632367830d/multi/vim/colors/zenburn.vim). (Several colorschemes that had this problem before now just have black backgrounds and don't have problems: jellybeans, zellner, xoria256, sandydune.) From vim, I can issue `:redraw!` and the background looks correct. (The `!` makes the screen get cleared first and without that, it doesn't draw the background correctly.) Either of these vim configuration settings will make the problem go away, but at the cost of reduced colours: ```vim set term=xterm set t_Co=16 ``` I'm using the bash.exe that came with installing WSL (Ubuntu -- the one that keeps updating to the latest LTS). I ran [this color test](https://github.com/microsoft/terminal/issues/70#issuecomment-366113395) here's the output: ![image](https://user-images.githubusercontent.com/43559/76811804-215efe00-67b0-11ea-905f-1ae6aae726f4.png) When I resize the window, all color lines become painted to the end. I guess that's equivalent to issuing a redraw from vim?
claunia commented 2026-01-31 00:50:23 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 17, 2020):

I suspect this is just #832, but the conhost fix for that won't be available until the next Windows update (version 2004 I think). It should be working in Windows Terminal, though.

That last bit about the colors painting to the end of the line when resizing is a separate issue (#32).

@j4james commented on GitHub (Mar 17, 2020): I suspect this is just #832, but the conhost fix for that won't be available until the next Windows update (version 2004 I think). It should be working in Windows Terminal, though. That last bit about the colors painting to the end of the line when resizing is a separate issue (#32).
claunia commented 2026-01-31 00:50:23 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 17, 2020):

Actually, yeah -- I can't reproduce this with the newest OpenConsole build from this repo. I'm gonna call this one a /dupe of #832, and I'm sorry to ask you to do a bunch of footwork to file another issue! It'll be out with the 2004 version of Windows.

@DHowett-MSFT commented on GitHub (Mar 17, 2020): Actually, yeah -- I can't reproduce this with the newest OpenConsole build from this repo. I'm gonna call this one a /dupe of #832, and I'm sorry to ask you to do a bunch of footwork to file another issue! It'll be out with the 2004 version of Windows.
claunia commented 2026-01-31 00:50:23 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 17, 2020):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Mar 17, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
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 Resolution-Duplicate
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#6914
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?