-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OperatorColor and ParameterColor are same color as background on Solarized Dark #4047
Comments
That's just the way the Solarized Dark color scheme is setup. The default background color is set to "bright black" rather than "black", so if the foreground is set to "bright black", it's going to invisible. Frankly it's just not a good color scheme for a terminal. |
I see. What is the intent/reason that it is set up in this manner? I do not recall having this issue using this theme in other terminals. |
My understanding is the Solarized scheme was originally designed for syntax highlighting, and it doesn't have the right range of colors for a terminal color scheme. Trying to use that exact same palette just doesn't map very well to terminal colors, and no mapping of that sort will ever be sensible (although the "official" one seems particularly bad IMHO). As for why you may not have this problem in other terminals, it's likely they just aren't using the official Solarized colors. Conemu, for example, has four variations of the Solarized scheme, none of which match the official colors. So if there is some version of the scheme that you like in another terminal, I'd recommend you just convert those values into an equivalent Windows Terminal scheme. |
Looks like this has been answered. Thanks everyone! |
The provided Solarized Dark color scheme is unusable. I just wrote a long ffmpeg command and I absolutely needed to use a different scheme in order to fix a minor issue ( If the advice is for users to substitute their own scheme, I strongly recommend removing the default Solarized Dark scheme. Anyone using it is going to have a bad time, and by extension, have a bad time using Windows Terminal. |
This is still an issue, it should not be closed. It is closely related to #6390 which is still open. The Solarized Dark theme that is included with the current version of Terminal defines In all other color schemes defined in The following steps reproduce the issue:
Expected: I can enter a basic PowerShell command that uses flags, and see the text that I type. Actual: Flag text is the same color as the background, and therefore cannot be seen unless it is highlighted. |
Original notes from @M-Pixel: > Console applications assume that backgrounds are black, and that > `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This > assumption is accounted for by all color schemes in `defaults.json`, > except for the Solarized themes. > > The Solarized Dark theme, in particular, makes `-Parameters` invisible > against the background in PowerShell, which is obviously an unacceptable > usability flaw. > > This change makes `black` and `background` to the same (which is common > throughout the color schemes), and makes `brightBlack` (`DarkGray` in > .NET) lighter than black (which is obviously more correct given the > meanings of those words). Out of the box, we ship a pretty bad behavior. If I look at all of the existing shipped color schemes--and that includes things like Tango and One Half--we are universally following a `background` == `black` rule. If I consult gnome-terminal or xterm, they do the same thing; Xterm by default, gnome-terminal for solarized. The background generally matches color index `0` across all their **dark** schemes. Konsole and lxterminal disagree and map background to `0 intense` for Solarized. I want to put our Solarized schemes on a deprecation path, but unfortunately we still need to ship _something_ for users who we're going to strand on them. I'm going to have to swallow my bitter and say that yes, we should probably just change the index mapping and go with something that works right out of the box while we figure out how to do perceptual color nudging and eventually remove bad defaults (like Solarized). From #6618. Fixes #4047. Closes #6618.
Original notes from @M-Pixel: > Console applications assume that backgrounds are black, and that > `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This > assumption is accounted for by all color schemes in `defaults.json`, > except for the Solarized themes. > > The Solarized Dark theme, in particular, makes `-Parameters` invisible > against the background in PowerShell, which is obviously an unacceptable > usability flaw. > > This change makes `black` and `background` to the same (which is common > throughout the color schemes), and makes `brightBlack` (`DarkGray` in > .NET) lighter than black (which is obviously more correct given the > meanings of those words). Out of the box, we ship a pretty bad behavior. If I look at all of the existing shipped color schemes--and that includes things like Tango and One Half--we are universally following a `background` == `black` rule. If I consult gnome-terminal or xterm, they do the same thing; Xterm by default, gnome-terminal for solarized. The background generally matches color index `0` across all their **dark** schemes. Konsole and lxterminal disagree and map background to `0 intense` for Solarized. I want to put our Solarized schemes on a deprecation path, but unfortunately we still need to ship _something_ for users who we're going to strand on them. I'm going to have to swallow my bitter and say that yes, we should probably just change the index mapping and go with something that works right out of the box while we figure out how to do perceptual color nudging and eventually remove bad defaults (like Solarized). From #6618. Fixes #4047. Closes #6618. (cherry picked from commit 04f5ee7)
Original notes from @M-Pixel: > Console applications assume that backgrounds are black, and that > `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This > assumption is accounted for by all color schemes in `defaults.json`, > except for the Solarized themes. > > The Solarized Dark theme, in particular, makes `-Parameters` invisible > against the background in PowerShell, which is obviously an unacceptable > usability flaw. > > This change makes `black` and `background` to the same (which is common > throughout the color schemes), and makes `brightBlack` (`DarkGray` in > .NET) lighter than black (which is obviously more correct given the > meanings of those words). Out of the box, we ship a pretty bad behavior. If I look at all of the existing shipped color schemes--and that includes things like Tango and One Half--we are universally following a `background` == `black` rule. If I consult gnome-terminal or xterm, they do the same thing; Xterm by default, gnome-terminal for solarized. The background generally matches color index `0` across all their **dark** schemes. Konsole and lxterminal disagree and map background to `0 intense` for Solarized. I want to put our Solarized schemes on a deprecation path, but unfortunately we still need to ship _something_ for users who we're going to strand on them. I'm going to have to swallow my bitter and say that yes, we should probably just change the index mapping and go with something that works right out of the box while we figure out how to do perceptual color nudging and eventually remove bad defaults (like Solarized). From #6618. Fixes #4047. Closes #6618. (cherry picked from commit 04f5ee7)
🎉This issue was addressed in #6985, which has now been successfully released as Handy links: |
1 similar comment
🎉This issue was addressed in #6985, which has now been successfully released as Handy links: |
🎉This issue was addressed in #6985, which has now been successfully released as Handy links: |
Environment
Steps to reproduce
Leaving other settings as default, set on the profile:
"colorScheme": "Solarized Dark"
Expected behavior
Text is not the same color as the background.
Actual behavior
OperatorColor
andParameterColor
are same color as backgroundThe text was updated successfully, but these errors were encountered: