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

Deprecate and eventually replace Solarized #9720

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

Originally created by @DHowett on GitHub (Jul 22, 2020).

Ideas for deprecation include shipping it built in but not in defaults.json and patching it into the user's settings when they're using it.

Originally created by @DHowett on GitHub (Jul 22, 2020). Ideas for deprecation include shipping it built in but not in defaults.json and patching it into the user's settings when they're using it.
claunia added the Area-SettingsIssue-TaskNeeds-Tag-FixProduct-Terminal labels 2026-01-31 02:02:10 +00:00
claunia commented 2026-01-31 02:02:11 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 22, 2020):

shipping it built in but not in defaults.json

This seems like the easiest solution

@zadjii-msft commented on GitHub (Jul 22, 2020): > shipping it built in but not in defaults.json This seems like the easiest solution
claunia commented 2026-01-31 02:02:11 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Mar 27, 2021):

I just went through and corrected a couple problems in the Solarized Dark and Light themes based on the published standard. When you are saying deprecate and replace are you talking about when it was already in the defaults.json before the Settings UI?

@rbeesley commented on GitHub (Mar 27, 2021): I just went through and corrected a couple problems in the Solarized Dark and Light themes based on the [published standard](https://ethanschoonover.com/solarized/). When you are saying deprecate and replace are you talking about when it was already in the defaults.json _before_ the Settings UI?
claunia commented 2026-01-31 02:02:11 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Apr 9, 2021):

@DHowett and @zadjii-msft, any guidance about what deprecating means in this context? I think this color scheme will continue to be supported and this issue is describing the behaviour of the Settings UI, where it adds the color scheme to the settings.json when it is selected in the interface.

@rbeesley commented on GitHub (Apr 9, 2021): @DHowett and @zadjii-msft, any guidance about what deprecating means in this context? I think this color scheme will continue to be supported and this issue is describing the behaviour of the Settings UI, where it adds the color scheme to the settings.json when it is selected in the interface.
claunia commented 2026-01-31 02:02:11 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 11, 2021):

The problem is that the real Solarized color schemes are a bit rubbish, and they were a constant source of bug reports because they make certain common color combinations invisible (one example in particular being the parameter colors in PowerShell).

At one point we were planning to deprecate them, so they wouldn't be one of the default themes available to new users. But in the end it was decided to just tweak the colors so that they didn't break PowerShell and hope that kept everyone happy.

I was convinced we'd still get a bunch of complaints from hardcore Solarized fans insisting we use the official colors, but that doesn't appear to have happened. So I suspect we aren't actually planning the deprecation anymore.

The one thing I am fairly certain of: we won't be changing the colors back to the published standard. That's a nightmare that nobody here wants to relive.

Edit: Just found the PR where we applied the Solarized "fix". See PR #6985 for more details.

@j4james commented on GitHub (Apr 11, 2021): The problem is that the real Solarized color schemes are a bit rubbish, and they were a constant source of bug reports because they make certain common color combinations invisible (one example in particular being the parameter colors in PowerShell). At one point we were planning to deprecate them, so they wouldn't be one of the default themes available to new users. But in the end it was decided to just tweak the colors so that they didn't break PowerShell and hope that kept everyone happy. I was convinced we'd still get a bunch of complaints from hardcore Solarized fans insisting we use the official colors, but that doesn't appear to have happened. So I suspect we aren't actually planning the deprecation anymore. The one thing I am fairly certain of: we won't be changing the colors back to the published standard. That's a nightmare that nobody here wants to relive. Edit: Just found the PR where we applied the Solarized "fix". See PR #6985 for more details.
claunia commented 2026-01-31 02:02:11 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Apr 11, 2021):

@j4james, thank you, that explains a lot. I have contributed to cmd-colors-solarized in the past and have worked with Paul to make Solarized color schemes work with cmd and PS before Windows Terminal, and I was investigating a bug someone submitted there.

One of my "fixes" I was considering for submission here was that there is a difference in base03 and base02 and how it is defined in the official spec. There's something else which doesn't seem to align in the base* range, but I haven't worked out where that issue exists. And lastly, I think Solarized Light is incorrect... While it technically matches the way the spec names the base* range, the color scheme has an expectation that the application would know that the dark text foreground should be base0 and when switched to light it should be base00. This means that the shell or an application would need to be aware of the context it is running in and this is how it is encoded as a color scheme in Windows Terminal. The additional thing I have prepared is that the base03-base3 entries are inverted. This makes it so that the output from applications don't need to care and they will do the right thing.

This would provide this result, using the current definition of Solarized Dark:
image

With my proposed inversion applied to Solarized Light, perhaps as an alternate Solarized Light variant:
image

Which would resolve this current mess:
image

For the purpose of usability, with the Solarized Light color scheme applied, the colors intended for grayscale use should be flipped while preserving the actual colors. Black might not be black, but as it comes to how the output is rendered, this inversion seems more appropriate.

@rbeesley commented on GitHub (Apr 11, 2021): @j4james, thank you, that explains a lot. I have contributed to cmd-colors-solarized in the past and have worked with Paul to make Solarized color schemes work with cmd and PS before Windows Terminal, and I was investigating a bug someone submitted there. One of my "fixes" I was considering for submission here was that there is a difference in base03 and base02 and how it is defined in the official spec. There's something else which doesn't seem to align in the base* range, but I haven't worked out where that issue exists. And lastly, I think Solarized Light is incorrect... While it technically matches the way the spec names the base* range, the color scheme has an expectation that the application would know that the dark text foreground should be base0 and when switched to light it should be base00. This means that the shell or an application would need to be aware of the context it is running in and this is how it is encoded as a color scheme in Windows Terminal. The additional thing I have prepared is that the base03-base3 entries are inverted. This makes it so that the output from applications don't need to care and they will do the right thing. This would provide this result, using the current definition of Solarized Dark: ![image](https://user-images.githubusercontent.com/3703112/114322914-a281e500-9ad7-11eb-91e1-c9467390ab07.png) With my proposed inversion applied to Solarized Light, perhaps as an alternate Solarized Light variant: ![image](https://user-images.githubusercontent.com/3703112/114322931-bc232c80-9ad7-11eb-9b2e-9e084d7e5318.png) Which would resolve this current mess: ![image](https://user-images.githubusercontent.com/3703112/114322943-cf35fc80-9ad7-11eb-9d71-9dc748177d2d.png) For the purpose of usability, with the Solarized Light color scheme applied, the colors intended for grayscale use should be flipped while preserving the actual colors. Black might not be black, but as it comes to how the output is rendered, this inversion seems more appropriate.
claunia commented 2026-01-31 02:02:11 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 11, 2021):

One of my "fixes" I was considering for submission here was that there is a difference in base03 and base02 and how it is defined in the official spec.

That's what PR #6985 was all about. We deliberately made that change.

@j4james commented on GitHub (Apr 11, 2021): > One of my "fixes" I was considering for submission here was that there is a difference in base03 and base02 and how it is defined in the official spec. That's what PR #6985 was all about. We deliberately made that change.
claunia commented 2026-01-31 02:02:11 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Apr 12, 2021):

That's why what I was showing in the photos is just inverting the base* for Solarized Light and doesn't have the correction which also flips the equivalent of Black and Dark Gray, as per the issue referenced. The advantage of this proposed change is that it makes switching from the Dark scheme to the Light scheme as more than just switching the Foreground and Background colors, but it keeps the relative intensities the same and applies the scheme more closely with how it is intended. Foreground and Background colors seem better supported now, so I think there is still value in matching the termcolors values, but I can detail that in an issue specific to the changes and we can shift discussion there.

@rbeesley commented on GitHub (Apr 12, 2021): That's why what I was showing in the photos is just inverting the base* for Solarized Light and doesn't have the correction which also flips the equivalent of Black and Dark Gray, as per the issue referenced. The advantage of this proposed change is that it makes switching from the Dark scheme to the Light scheme as more than just switching the Foreground and Background colors, but it keeps the relative intensities the same and applies the scheme more closely with how it is intended. Foreground and Background colors seem better supported now, so I think there is still value in matching the termcolors values, but I can detail that in an issue specific to the changes and we can shift discussion there.
claunia commented 2026-01-31 02:02:12 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Apr 12, 2021):

@j4james, and now going back through all of this I'm reminded about why this is so frustrating to work with. Yellow warnings are gray and red errors are orange... which is why with cmd-colors-solarized we inverted the bright/dark relationship so that red was always red and yellow was always yellow. See @TBBle's comment on issue #6985. I think I can provide a profile fix (or maybe that's already part of Paul's Solarized canon wiki link), and we'd be able to fix the output for errors and warnings, but Gray/White aka Color Table 7, seems to be still locked to a specific color, so not a perfect fix, but I think this will improve readability when switching between dark and light variants. TBD. Thanks for getting me caught up on the history and the reason for this issue.

@rbeesley commented on GitHub (Apr 12, 2021): @j4james, and now going back through all of this I'm reminded about why this is so frustrating to work with. Yellow warnings are gray and red errors are orange... which is why with cmd-colors-solarized we inverted the bright/dark relationship so that red was always red and yellow was always yellow. See @TBBle's [comment](https://github.com/microsoft/terminal/pull/6985#issuecomment-663518517) on issue #6985. I think I can provide a profile fix (or maybe that's already part of Paul's Solarized canon wiki link), and we'd be able to fix the output for errors and warnings, but Gray/White aka Color Table 7, seems to be still locked to a specific color, so not a perfect fix, but I think this will improve readability when switching between dark and light variants. TBD. Thanks for getting me caught up on the history and the reason for this issue.
claunia commented 2026-01-31 02:02:12 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Apr 12, 2021):

I probably should go check that I haven't made any meaningful local changes to my "canon solarized setup" and not committed them, in case others actually look at it.

I do roughly agree with the WT maintainers that canon Solarized in the default profile breaks a bunch of expectations, but I say that coming from the position of several years of Solarized use, and so I have the expectation already that if I want to use Solarized in a terminal, I have to plumb the config a long way through. Generally these days, I plumb it through to RGB-supporting programs, rather than relying on the 16-colour terminal palette. I think PowerShell and PS-Readline are the only things still generating 16-colour codes, but I'm not using Linux very much, so wouldn't have noticed if dircolors (for example) was mismapping over an SSH session.

That's why I suggested perhaps replacing Solarized in the default config with, e.g. Selenized, which is basically tuned Solarized, but with the major advantage that it tries to map to the 16-colour ANSI palette sensibly, so should do the right thing as a default colour theme, where Solarized cannot without breaking all the existing users.

The "if you say colour 7, Terminal turns that into BG" thing was a workaround for old PowerShell (PS-Readline technically) in #6810, and that will eventually be dropped from Terminal. The PS-Readline fix merged in July 2020, and PS-Readline 2.1.0 with the fix was GA in November 2020, so perhaps it's time to revert #6810 and close #6807? Or is there some other delivery pipeline that needs to pump first, e.g., is inbox PS-Readline a concern?

@TBBle commented on GitHub (Apr 12, 2021): I probably should go check that I haven't made any meaningful local changes to my "canon solarized setup" and not committed them, in case others actually look at it. I do roughly agree with the WT maintainers that canon Solarized in the default profile breaks a bunch of expectations, but I say that coming from the position of several years of Solarized use, and so I have the expectation already that if I want to use Solarized in a terminal, I have to plumb the config a long way through. Generally these days, I plumb it through to RGB-supporting programs, rather than relying on the 16-colour terminal palette. I think PowerShell and PS-Readline are the only things still generating 16-colour codes, but I'm not using Linux very much, so wouldn't have noticed if dircolors (for example) was mismapping over an SSH session. That's why I suggested perhaps replacing Solarized in the default config with, e.g. [Selenized](https://github.com/jan-warchol/selenized/), which is basically tuned Solarized, but with the major advantage that it tries to map to the 16-colour ANSI palette sensibly, so should do _the right thing_ as a default colour theme, where Solarized cannot without breaking all the existing users. ---- The "if you say colour 7, Terminal turns that into BG" thing was a workaround for old PowerShell (PS-Readline technically) in #6810, and that will eventually be dropped from Terminal. The PS-Readline fix merged in July 2020, and PS-Readline 2.1.0 with the fix was GA in November 2020, so perhaps it's time to revert #6810 and close #6807? Or is there some other delivery pipeline that needs to pump first, e.g., is inbox PS-Readline a concern?
claunia commented 2026-01-31 02:02:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 19, 2021):

DAYS SINCE I'VE REGRETTED SHIPPING SOLARIZED: 0

@zadjii-msft commented on GitHub (Apr 19, 2021): ### [DAYS SINCE I'VE REGRETTED SHIPPING SOLARIZED: 0](https://github.com/microsoft/terminal/issues/9887)
claunia commented 2026-01-31 02:02:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 8, 2021):

hot take, with the auto-adjustment in #11095, we should close this. We can leave Solarized in now, because it will be less painful. (not not painful, just, less). Thoughts?

@zadjii-msft commented on GitHub (Dec 8, 2021): hot take, with the auto-adjustment in #11095, we should close this. We can leave Solarized in now, because it will be less painful. (not _not_ painful, just, less). Thoughts?
claunia commented 2026-01-31 02:02:13 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 8, 2021):

Agreed. Perceptual color nudging is the "boots on the ground" solution to color schemes that are not properly perceptible. 😄

@DHowett commented on GitHub (Dec 8, 2021): Agreed. Perceptual color nudging is the "boots on the ground" solution to color schemes that are not properly perceptible. :smile:
claunia commented 2026-01-31 02:02:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 8, 2021):

Good enough for me.

@zadjii-msft commented on GitHub (Dec 8, 2021): Good enough for me.
claunia commented 2026-01-31 02:02:13 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Dec 9, 2021):

I'll have to go look at what #11095 changes, but it sounds like it will fix the problems I was trying to address with tweaking the color scheme. If so, then I am probably prefectly fine with this. I think the effect of inverting should have the actual effect of inverting the colors in a way which preserves hue and adjusts things so that readability is maintained, but the essence of the solarized color scheme is there.

@rbeesley commented on GitHub (Dec 9, 2021): I'll have to go look at what #11095 changes, but it sounds like it will fix the problems I was trying to address with tweaking the color scheme. If so, then I am probably prefectly fine with this. I think the effect of inverting should have the actual effect of inverting the colors in a way which preserves hue and adjusts things so that readability is maintained, but the essence of the solarized color scheme is there.
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 Issue-Task Needs-Tag-Fix 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#9720
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?