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

Campbell color scheme should change the foreground color from #F2F2F2 to #CCCCCC #1807

New Issue
Closed
opened 2026-01-30 22:36:56 +00:00 by claunia · 5 comments
claunia commented 2026-01-30 22:36:56 +00:00
Owner
Copy Link

Originally created by @rbeesley on GitHub (Jun 21, 2019).

Campbell color scheme should change the foreground color from #F2F2F2 to #CCCCCC

The problem with the current Campbell color scheme is that it has no range for the default terminal "white." ESC[m, ESC[97m, ESC[1m, ESC[1;30m, and ESC[1;37m are all the same #F2F2F2 color, "brightWhite." Just changing the foreground from "brightWhite" to "white" means that ESC[m, and ESC[37m are shown as "white" while ESC[1m, ESC[1;30m, and ESC[1;37m are "brightWhite." When you consider what these values mean, it really makes sense that this is how the scheme should be defined. Looking at the intersection of 37m/47m you can see how this really stands out in the current scheme as it breaks the diagonal. With the current Campbell color scheme, you can't even address "white" except as a background color.

Current Campbell:
image

Proposed Campbell:
image

Proposed technical implementation details

{
  "schemes" :
  [
    {
      "background" : "#0C0C0C",
      "black" : "#0C0C0C",
      "blue" : "#0037DA",
      "brightBlack" : "#767676",
      "brightBlue" : "#3B78FF",
      "brightCyan" : "#61D6D6",
      "brightGreen" : "#16C60C",
      "brightPurple" : "#B4009E",
      "brightRed" : "#E74856",
      "brightWhite" : "#F2F2F2",
      "brightYellow" : "#F9F1A5",
      "cyan" : "#3A96DD",
      "foreground" : "#CCCCCC",
      "green" : "#13A10E",
      "name" : "Campbell",
      "purple" : "#881798",
      "red" : "#C50F1F",
      "white" : "#CCCCCC",
      "yellow" : "#C19C00"
    }
  ]
}
Originally created by @rbeesley on GitHub (Jun 21, 2019). # Campbell color scheme should change the foreground color from #F2F2F2 to #CCCCCC The problem with the current Campbell color scheme is that it has no range for the default terminal "white." ESC[m, ESC[97m, ESC[1m, ESC[1;30m, and ESC[1;37m are all the same #F2F2F2 color, "brightWhite." Just changing the foreground from "brightWhite" to "white" means that ESC[m, and ESC[37m are shown as "white" while ESC[1m, ESC[1;30m, and ESC[1;37m are "brightWhite." When you consider what these values mean, it really makes sense that this is how the scheme should be defined. Looking at the intersection of 37m/47m you can see how this really stands out in the current scheme as it breaks the diagonal. With the current Campbell color scheme, you can't even address "white" except as a background color. Current Campbell: ![image](https://user-images.githubusercontent.com/3703112/59894380-434c6100-9395-11e9-8a9e-443e48e9a603.png) Proposed Campbell: ![image](https://user-images.githubusercontent.com/3703112/59894392-4f382300-9395-11e9-8784-3531a5d5a86e.png) # Proposed technical implementation details ```JSON { "schemes" : [ { "background" : "#0C0C0C", "black" : "#0C0C0C", "blue" : "#0037DA", "brightBlack" : "#767676", "brightBlue" : "#3B78FF", "brightCyan" : "#61D6D6", "brightGreen" : "#16C60C", "brightPurple" : "#B4009E", "brightRed" : "#E74856", "brightWhite" : "#F2F2F2", "brightYellow" : "#F9F1A5", "cyan" : "#3A96DD", "foreground" : "#CCCCCC", "green" : "#13A10E", "name" : "Campbell", "purple" : "#881798", "red" : "#C50F1F", "white" : "#CCCCCC", "yellow" : "#C19C00" } ] }
claunia commented 2026-01-30 22:36:57 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jun 21, 2019):

Is this just a fancy way to report #293?

@DHowett-MSFT commented on GitHub (Jun 21, 2019): Is this just a fancy way to report #293?
claunia commented 2026-01-30 22:36:57 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Jun 21, 2019):

@DHowett-MSFT, no that wasn't my intent. It might be related, but I'll explain more and hopefully I can make it a little more clear.

This is specifically about the color palette of Campbell. The choice was made to make the foreground text #F2F2F2, or "brightWhite." The negative about that choice is that the default terminal color is then set to "brightWhite" for ESC[m, and ESC[37m. As another experiment to understand how things work, I set the "foreground" property to #DCDCDC, this is the average of "white" and "brightBlack." More importantly it is not the same as "black," "brightBlack," "white," or "brightWhite." It's the most average gray I could create without making more extensive changes to the color scheme. With that selected, ESC[m was showing #DCDCDC, but disappointingly ESC[37m was now also showing #DCDCDC and not #CCCCCC.

I believe this is the same issue as where cmd.exe in conhost.exe only had 16 colors instead of the full number of colors available to xterm, supporting colors 0-15, foreground, background, and cursor. ESC[m and ESC[39m I believe would be the same, being default display color as defined by ECMA-48 and I believe referenced in xterm as foreground. As I understand it, because Windows only supported 16 colors, there is some "magic" which tries to map the 16 colors to the extended palette as was used by xterm in WSL. It's not a 1:1 matching. Ideally, foreground, background, and cursorColor would be colors outside that palette of 16, so it'd be 16+3 (or 4 as I think I saw another feature request for having a cursor background color).

I mention this because it seems to affect how ESC[1m works. By setting bold/intensity you're flipping the high bit. ESC[37m is "white," and ESC[1;37m is "brightWhite." The "foreground" property appears to map to ESC[37m.

So, the consequence of how this "magic" happens, if the "foreground" is set to #F2F2F2, it already maps to "brightWhite" so there is no way to make the default/foreground color any more intense. If you change the foreground to #CCCCCC, that matches "white." Therefore when you set the intensity bit for that color, it matches "brightWhite." Without lowering the intensity for "foreground" you can't use any escape sequence to set the foreground to "white." You will only be able to set the background "white" with ESC[47m.

So examining #293, it's possible that enabling the full set of colors would partially resolve this, but for ConPTY consumers which don't have the extended palette, making this adjustment would automatically improve things.

I hope that explains it. I'm still learning this myself so I might not fully understand how it all fits together, but this seems like how everything is working.

@rbeesley commented on GitHub (Jun 21, 2019): @DHowett-MSFT, no that wasn't my intent. It might be related, but I'll explain more and hopefully I can make it a little more clear. This is specifically about the color palette of Campbell. The choice was made to make the foreground text #F2F2F2, or "brightWhite." The negative about that choice is that the default terminal color is then set to "brightWhite" for ESC[m, and ESC[37m. As another experiment to understand how things work, I set the "foreground" property to #DCDCDC, this is the average of "white" and "brightBlack." More importantly it is not the same as "black," "brightBlack," "white," or "brightWhite." It's the most average gray I could create without making more extensive changes to the color scheme. With that selected, ESC[m was showing #DCDCDC, but disappointingly ESC[37m was now also showing #DCDCDC and not #CCCCCC. I believe this is the same issue as where cmd.exe in conhost.exe only had 16 colors instead of the full number of colors available to xterm, supporting colors 0-15, foreground, background, and cursor. ESC[m and ESC[39m I believe would be the same, being default display color as defined by [ECMA-48](http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf) and I believe referenced in xterm as foreground. As I understand it, because Windows only supported 16 colors, there is some "magic" which tries to map the 16 colors to the extended palette as was used by xterm in WSL. It's not a 1:1 matching. Ideally, foreground, background, and cursorColor would be colors outside that palette of 16, so it'd be 16+3 (or 4 as I think I saw another feature request for having a cursor background color). I mention this because it seems to affect how ESC[1m works. By setting bold/intensity you're flipping the high bit. ESC[37m is "white," and ESC[1;37m is "brightWhite." The "foreground" property appears to map to ESC[37m. So, the consequence of how this "magic" happens, if the "foreground" is set to #F2F2F2, it already maps to "brightWhite" so there is no way to make the default/foreground color any more intense. If you change the foreground to #CCCCCC, that matches "white." Therefore when you set the intensity bit for that color, it matches "brightWhite." Without lowering the intensity for "foreground" you can't use any escape sequence to set the foreground to "white." You will only be able to set the background "white" with ESC[47m. So examining #293, it's possible that enabling the full set of colors would partially resolve this, but for ConPTY consumers which don't have the extended palette, making this adjustment would automatically improve things. I hope that explains it. I'm still learning this myself so I might not fully understand how it all fits together, but this seems like how everything is working.
claunia commented 2026-01-30 22:36:58 +00:00
Author
Owner
Copy Link

@noinkling commented on GitHub (Jun 22, 2019):

If it's worth anything, this is a change I also made (before seeing this issue).

@noinkling commented on GitHub (Jun 22, 2019): If it's worth anything, this is a change I also made (before seeing this issue).
claunia commented 2026-01-30 22:36:58 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 3, 2019):

@rbeesly Thanks for the report and the fix! This was just submitted to the store with the v0.2.1831.0 servicing release. It may take some time for the store to process it.

@DHowett-MSFT commented on GitHub (Jul 3, 2019): @rbeesly Thanks for the report _and the fix_! This was just submitted to the store with the v0.2.1831.0 servicing release. It may take some time for the store to process it.
claunia commented 2026-01-30 22:36:58 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 3, 2019):

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

Handy links:

@ghost commented on GitHub (Aug 3, 2019): :tada:This issue was addressed in #1629, which has now been successfully released as `Windows Terminal Preview v0.3.2142.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
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-Settings Help Wanted Issue-Task Product-Meta Resolution-Fix-Available
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#1807
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?