Skip to content
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

Closed
duckness opened this issue Dec 23, 2019 · 9 comments · Fixed by #6985
Closed

OperatorColor and ParameterColor are same color as background on Solarized Dark #4047

duckness opened this issue Dec 23, 2019 · 9 comments · Fixed by #6985
Labels
Issue-Question For questions or discussion Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal. Resolution-Answered Related to questions that have been answered Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@duckness
Copy link

Environment

Windows build number: Microsoft Windows NT 10.0.18363.0
Windows Terminal version (if applicable): 0.7.3451.0

Any other software?

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 and ParameterColor are same color as background
WindowsTerminal_7iJtSJmZkh

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Dec 23, 2019
@j4james
Copy link
Collaborator

j4james commented Dec 25, 2019

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.

@duckness
Copy link
Author

duckness commented Dec 25, 2019

That's just the way the Solarized Dark color scheme is setup.

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.

@j4james
Copy link
Collaborator

j4james commented Dec 25, 2019

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.

@zadjii-msft zadjii-msft added Resolution-Answered Related to questions that have been answered Issue-Question For questions or discussion Product-Terminal The new Windows Terminal. labels Dec 30, 2019
@DHowett-MSFT
Copy link
Contributor

Looks like this has been answered. Thanks everyone!

@gavinbeatty
Copy link

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 (-metadata:s:a:0 language=eng must be quoted as "-metadata:s:a:0" language=eng in powershell).

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.

@M-Pixel
Copy link

M-Pixel commented Jun 20, 2020

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 brightBlack and background as the same color (source). brightBlack maps to [ConsoleColor]::DarkGray, which is the default color for Parameters in PowerShell 6.

In all other color schemes defined in defaults.json, black and background are set to the same values, or no other color has the same value as background; Solarized Dark is an anomaly in this regard. Unless somebody can justify this anomaly, it should be seen as a flaw that needs fixing.

The following steps reproduce the issue:

  • Install the latest version of Terminal from the Windows Store
  • Change the color scheme for PowerShell to Solarized Dark

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.

@ghost ghost added the In-PR This issue has a related PR label Jun 20, 2020
DHowett added a commit that referenced this issue Jul 20, 2020
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.
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Jul 20, 2020
DHowett added a commit that referenced this issue Jul 20, 2020
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)
DHowett added a commit that referenced this issue Jul 20, 2020
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)
@ghost
Copy link

ghost commented Jul 21, 2020

🎉This issue was addressed in #6985, which has now been successfully released as Windows Terminal v1.1.2021.0.:tada:

Handy links:

1 similar comment
@ghost
Copy link

ghost commented Jul 22, 2020

🎉This issue was addressed in #6985, which has now been successfully released as Windows Terminal v1.1.2021.0.:tada:

Handy links:

@ghost
Copy link

ghost commented Jul 22, 2020

🎉This issue was addressed in #6985, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Question For questions or discussion Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal. Resolution-Answered Related to questions that have been answered Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
6 participants