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

Color0 (black) being set and used as default background in Solarized Light theme #6286

Closed
djwf opened this issue Jun 1, 2020 · 4 comments
Closed
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@djwf
Copy link

djwf commented Jun 1, 2020

Environment

Microsoft Windows NT 10.0.19041.0
Windows Terminal Version: 1.0.1401.0
WSLtty Version: 3.1.4.2

Steps to reproduce

Enable the solarized light theme (add "colorScheme": "Solarized Light" to WSL profile).

Open Windows Terminal WSL console.

Execute the following printf "\033[49;39mDEFBG-DEFFG\033[40;39mCOLOR0-DEFFG\033[0m\n".

Expected behavior

The expected behavior is demonstrated by executing the printf command listed in steps to reproduce in wsltty, using the color configuration listed below.

ForegroundColour=101,123,131 # base00, #657b83
BackgroundColour=253,246,227 # base3,  #fdf6e3
CursorColour=38,139,210      # blue,   #268bd2
# Solarized colors for (min|wsl)tty.
# Color 0
Black=7,54,66           # base02,  #073642
# Color 1
Red=220,50,47           # red,     #dc322f
# Color 2
Green=133,153,0         # green,   #859900
# Color 3
Yellow=181,137,0        # yellow,  #b58900
# Color 4
Blue=38,139,210         # blue,    #268bd2
# Color 5
Magenta=211,54,130      # magenta, #d33682
# Color 6
Cyan=42,161,152         # cyan,    #2aa198
# Color 7
White=238,232,213       # base2,   #eee8d5
# Color 8
BoldBlack=0,43,54       # base03,  #002b36
# Color 9
BoldRed=203,75,22       # orange,  #cb4b16
# Color 10
BoldGreen=88,110,117    # base01,  #586e75
# Color 11
BoldYellow=101,123,131  # base00,  #657b83
# Color 12
BoldBlue=131,148,150    # base0,   #839496
# Color 13
BoldMagenta=108,113,196 # violet,  #6c71c4
# Color 14
BoldCyan=147,161,161    # base1,   #93a1a1
# Color 15
BoldWhite=253,246,227   # base3,   #fdf6e3

The result was the following:

wsltty-color0-defaultbg

The command colortest-8 can also be used to see the issue, by looking at the reverse section. In wsltty the reverse section is as follows.

wsltty-colortest-8-reverse

Actual behavior

The actual behavior is that the default background color seems to be written to color0 ("black" in the color scheme). See the outcome of the printf command listed in steps to reproduce executed in a Windows Terminal WSL console below.

winterm-color0-defaultbg

Note that the default background color in the image is the same as color0, even though the Solarized Light scheme defines them to be different colors. This can also be seen in the output of colortest-8, where the background of the header of each row in the reverse section should be gray, and the background of the color named fields in the first row of the reverse section should be whatever the "black" color is set to, as seen below.

winterm-colortest-8-reverse

I also tried creating my own color scheme by copying the Solarized Light scheme, and making sure the background, foreground, and black (color0) colors were set (see scheme below). The results were the same as using the built in Solarized Light.

        {
            "name": "Solarized Light (djwf)",
            "foreground": "#657B83",
            "background": "#FDF6E3",
            "cursorColor": "#268BD2",
            "black": "#073642",
            "red": "#DC322F",
            "green": "#859900",
            "yellow": "#B58900",
            "blue": "#268BD2",
            "purple": "#D33682",
            "cyan": "#2AA198",
            "white": "#EEE8D5",
            "brightBlack": "#002B36",
            "brightRed": "#CB4B16",
            "brightGreen": "#586E75",
            "brightYellow": "#657B83",
            "brightBlue": "#839496",
            "brightPurple": "#6C71C4",
            "brightCyan": "#93A1A1",
            "brightWhite": "#FDF6E3"
        }

I think that's it, please let me know if you need more information.

@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 Jun 1, 2020
@DHowett
Copy link
Member

DHowett commented Jun 1, 2020

Thanks for the report! This is another version of #293 -- we were changing the palette in legacy applications for compatibility reasons. We'll be fixing that shortly.

/sup #293.

@DHowett
Copy link
Member

DHowett commented Jun 1, 2020

heh. /dup #293. 😄

@ghost
Copy link

ghost commented Jun 1, 2020

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Jun 1, 2020
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed 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 Jun 1, 2020
@djwf
Copy link
Author

djwf commented Jun 1, 2020

Whoops: I thought I'd searched sufficiently, but apparently not. Thanks for the heads up and link!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

2 participants