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

Vim background colors are incorrectly drawn when scrolling #6911

New Issue
Open
opened 2026-01-31 00:50:19 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 00:50:19 +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:19 +00:00
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#6911
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?