Text is unreadable with Solarized Dark theme in iTerm2 because colors are similar to background

[amingilani]

Describe the bug

With iterm2's Solarized Dark theme, the current default theme is unreadable in commands like:

• gh repo view
• gh issue view

gh version 1.0.0 (2020-09-16)
https://github.com/cli/cli/releases/tag/v1.0.0

This is due to the fact that the dark text colors blend in with the background. See screenshots.

Steps to reproduce the behavior

1. Change item2 to use the Solarized Dark theme
2. Run the commands above
3. Try to read the output

Expected vs actual behavior

Readable output

Screenshots

[vilmibm]

Sorry about this; I think this has to do with macos's dark mode setting not informing terminal applications whether the background is light or dark.

for reference, here's output on solarized dark in gnome-terminal:

@mislav runs macos and will be of more help here, but I think until we come up with a better solution the workaround might be explicitly switching color schemes from light->dark from within iterm2?

[amingilani]

Hmmm, that may be true. That said, changing to dark themes does not have an effect. In fact, none of the options have any effect on how the text blends with the background.

[amingilani]

Is there a way to force the correct color scheme through gh config?

[mislav]

@amingilani Thank you for reporting! I just tried to reproduce in iTerm2 with Solarized Dark, but could not.

Do you have GLAMOUR_STYLE set in your environment variables by any chance?

[corytheboyd]

This same thing happens for me:

Do you have GLAMOUR_STYLE set in your environment variables by any chance?

FWIW this variable is not set in my environment.

[LiteracyFanatic]

I just wanted to chime in that this isn't just an issue with dark themes; the gray text is very hard to read if you have a transparent terminal window as well.

[ct-clearhaus]

As a work-around, one can adjust the iTerm2's "Minimum Contrast" setting (hit Cmd+i -> "Colors" tab -> "Minimum Contrast" slider):

[mislav]

@amingilani @corytheboyd If GLAMOUR_STYLE variable isn't set, you can set it manually to either GLAMOUR_STYLE=dark (for dark themes) or GLAMOUR_STYLE=light (for light themes). We try to detect the terminal background color automatically when rendering Markdown, but this doesn't always work.

@LiteracyFanatic Good to know about gray not being readable! We hope to make the color palette configurable so that users with specific needs can customize the base set of colors.

@ct-clearhaus Thank you for the workaround!

[vilmibm]

GLAMOUR_STYLE makes sense to support as other CLI programs use glamour; however, it might be a good enhancement to expose a light/dark toggle via gh config as was suggested (that is just an abstraction over GLAMOUR_STYLE).

[amingilani]

Thanks @mislav, I can confirm that setting GLAMOUR_STYLE=dark fixed this for me.

Here's a workaround until the new release comes out. Copy the following lines in your .zshrc or .bashrc file:

# Temporary workaround for GitHub CLI readability problems.
# Remove if this issue is closed: https://github.com/cli/cli/issues/1743
if [ `defaults read -g AppleInterfaceStyle` = "Dark" ]; then
    export GLAMOUR_STYLE=dark
else
    export GLAMOUR_STYLE=light
fi

[camelid]

Just want to note that this occurs in vanilla macOS Terminal as well:

The workaround posted at #1743 (comment) fixes it.

By the way, thanks for fixing the issue where the colors wouldn't be cleaned up after running gh! ❤️

[blacksails]

I have issues on Gnome terminal with solarized dark gh pr view 2214 on the gh cli repo gives this output:

I marked the areas where text color is the same as background color. The problem with the solarized theme is that it uses the bright colors as different shades of grey. In the example above the text is using the bright variant of black, which in solarized is the same as the background color. If the gh cli stuck with the first 8 colors and refrained from using the bright variants, then there should be no issues with the solarized theme.

[mislav]

@blacksails Are you running a recent version of GitHub CLI? Does setting GLAMOUR_STYLE=dark fixes it for you?

[blacksails]

@mislav Running v0.12.0 output is the same when setting GLAMOUR_STYLE=dark

[blacksails]

Should I create a new issue for Gnome terminal + gh cli + solarized colors? or maybe just gh cli + solarized, as this shouldn't really be a problem with the terminal emulator, but more a support issue with how the gray color is rendered, when using solarized.

[blacksails]

The problem is here https://github.com/cli/cli/blob/trunk/pkg/iostreams/color.go#L18 because the solarized theme uses bright green as gray. This line should be gray = ansi.ColorFunc("green+h") when using solarized.

[mislav]

@blacksails Would you update to the latest version and try again? I'm pretty sure we fixed this issue in v1.0 back in September https://github.com/cli/cli/releases/tag/v1.0.0

[blacksails]

@mislav sorry about the confusion, this has indeed been fixed.

[mislav]

Thank you all for your input! Closing because we haven't got any reports of this being broken in the last 2 months.

Our background color detection can still be broken when Terminal.app is used in macOS "Dark" mode. If you are affected by this, please refer to the workaround above. 🙇

[camelid]

Our background color detection can still be broken when Terminal.app is used in macOS "Dark" mode. If you are affected by this, please refer to the workaround above. 🙇

Is there an issue tracking the macOS issue? It's unfortunate to require users to use a workaround. Is there any way the workaround could be integrated into gh directly?

[mislav]

Is there an issue tracking the macOS issue? It's unfortunate to require users to use a workaround.

I consider this to be a bug in Terminal.app in dark mode and not as something that we need or can fix from GitHub CLI. But you are right that potentially a lot of people can be affected by this, so I'm opening a new issue to track this, mainly to see how many upvotes it gets over time.

Is there any way the workaround could be integrated into gh directly?

Well, we could in theory embed a defaults read -g AppleInterfaceStyle call to every invocation of gh, which feels risky to me especially because, in my experience, Apple changes the names of their preferences anyway. I have a dotfiles script that sets a bunch of defaults write ... and I have noticed how many of them got broken over the years.