More nuanced color support

Changing the colour of text in terminals is tricky, because you never know what the background colour is, so the text may be unreadable or just look ugly. This is especially an issue with lighter backgrounds.

A -no-color switch or something to that would be useful. Right now I have to pipe stuff to cat to make the colours go away, which isn't very convenient.

@arp242

@arp242 It's possible (albeit tricky) to detect whether the terminal has a light or dark background. Alternatively, there are a few colors that work well on both.

Maybe something similar to ls --color flag would make sense like I suggested in #447 :

--color[=WHEN]
              colorize the output; WHEN can be 'always' (default if omitted), 'auto', or 'never'; more info below

@arp242

This is especially an issue with lighter backgrounds.

@arp242 Thank you for reporting! We would appreciate screenshots of low-readability of gh output in various terminal color configurations. (If the data is sensitive, you could run the same command against an open source repo.)

Git has excellent configurability regarding disabling/forcing/changing default colors— perhaps we should allow some configurability as well.

I'm using a white background on my terminal and also finding text, especially grey text very hard to read. I'm attaching a screenshot. Some configurability would be nice but I would prefer some nice defaults to start with that could work with common dark and light backgrounds.

Have the same issue with a white background. Especially bad with some inline code snippets:

I'd like to add that I'm piping output to fzf and I can't get any colors because they get disabled by default. Whatever solution is found here, I think it should also include the option to force colors.

Here's an example:

gh pr list | column -s $'\t' -t | fzf | awk '{print $1}' | xargs gh pr checkout

I also have a problem with color. I'm using Iterm2 Builtin Solarized Dark.

Gray color text is completely invisible as shown below.

It seems cli/cli v0.7.0 now supports NO_COLOR.
I wonder if it is desirable to implement something like gh config set color off to disable color only for gh command and gh config set color light to enable Light option for a white background. 🤔

Ultimately, I want to keep using my favorite terminal color scheme without disabling gh color output. 😢

In my opinion --no-color is something very useful however having an opportunity to have a coloured output tuned for white screen is even a better option.

we should have a light theme mode for sure. I don't think we have an issue for that yet.

is there any particular reason for the issue body text to be printed in a non-default colour? personally I find the grey text to be a little hard to read even on a dark background.

also the output of gh issue view is at least partially unreadable (either the body text or the author/timestamp) on both dark and light backgrounds for me, fwiw:

screenshots

is there any particular reason for the issue body text to be printed in a non-default colour? personally I find the grey text to be a little hard to read even on a dark background.

No real reason; it's just the default behavior of the markdown library we're using. Part of this issue should be auditing its palette to ensure legibility in more contexts.

This is a dark background/palette (dracula-based) in Alacritty; it's mildly more readable in Terminal.app (but the them is slightly different). Some text is effectively invisible:

Personally, I think this needs to be a bigger priority than it seems to be now (based on the Feb 12 issue creation and not much traction/progress to date). I understand that new features are fun or sexy, but gh doesn't yet meet a minimum of usability for certain users—and I don't think they should be ignored!

To put it a little more strongly, I am saddened that this is not a Must have in the backlog—there is a real accessibility concern here, not just an issue about "not my favorite colors." I understand if that needs to be a separate issue from this one. Even just the ability to stop using color altogether—or maybe rely on high contrast/bolding for a few elements—could be a big improvement. But you probably want to consult with someone who knows what they're talking about in this space.

Contrast seems to be the biggest legibility issue, based on the screenshots I'm seeing.

This patch disables color.

--- a/utils/utils.go
+++ b/utils/utils.go
@@ -24,7 +24,7 @@ func OpenInBrowser(url string) error {
 func RenderMarkdown(text string) (string, error) {
 	style := "notty"
 	if isColorEnabled() {
-		style = "dark"
+		style = "notty"
 	}
 	return glamour.Render(text, style)
 }

The following patch and glamour 20200527 would allow disabling color with the GLAMOUR_STYLE=notty environment variable. Or setting it to ansi, light, dark or a custom style the user creates.

--- a/utils/utils.go
+++ b/utils/utils.go
@@ -24,7 +24,7 @@ func OpenInBrowser(url string) error {
 func RenderMarkdown(text string) (string, error) {
 	style := "notty"
 	if isColorEnabled() {
-		style = "dark"
+		return glamour.RenderWithEnvironmentConfig(text)
 	}
 	return glamour.Render(text, style)
 }

@doi-t

Here is how one could currently disable color output from all gh commands:

setting the NO_COLOR environment variable
redirecting the output, e.g. gh repo view | cat

In the future we will add equivalents of --color=never and --color=always flags to explicitly disable or force color output.

I've opened a PR to address the issue with markdown rendering on light terminal backgrounds.

@doi-t I'm really puzzled by themes such as "Builtin Solarized Dark" in iTerm. Here is it in action:

Observe that "bold black" (1;30) that we use as equivalent for "gray" is virtually invisible, and other "bold" colors are mostly converted to grayscale.

For comparison, here is iTerm with a more default setting:

However, as more people report problems with how what we render "gray" looks in their color schemes, I'm beginning to think that we never should have used 1;30 ("bold/increased intensity black") as a way to render gray color jqlang/jq#1252. We will revisit this in subsequent updates.

I'm finding that the NO_COLOR environment variable isn't respected when I run gh pr create, meaning that the default suggested title for a pull request isn't visible on my light terminal background (I only realised it was there by highlighting the text). Would be good to see this addressed at the same time as markdown rendering.

@juanibiapina

Hi all 👋 thank you for all the reports!

We've fixed:

markdown rendering on light terminals: we released this a while ago
gray color rendering: on 256color-enabled terminals we now output true gray
inability to disable colors in prompts: setting NO_COLOR now disables colors even in prompts
the text representing the default value in prompts can be invisible: now fixed

For new issues with color that you experience in current trunk or after the next release, please open a new issue. 🙇

@juanibiapina Forcing colors is now possible using CLICOLOR_FORCE=1, but that still doesn't trigger the nice table + colors layout from gh issue/pr list that we reserve for TTY output only. We aim to enable the fzf usage as you are describing in a future release ✨

Awesome! I tested it with trunk branch and the gray color is now nicely printed out. 🤩

@mislav

Hello. Sorry for commenting on a closed and old issue. I'm currently struggling with displaying a nice preview functionality with fzf i.e. trying to do something like

$ gh pr list | fzf --preview 'gh pr view {1}'

but as mentioned here, the display in preview isn't very pretty.

@mislav you mentioned

We aim to enable the fzf usage as you are describing in a future release ✨

Any more details on that? Should I open a new issue?

@slafs

@slafs Feel free to open a new issue specifically about this.

@mislav

Hello. Sorry for commenting on a closed and old issue. I'm currently struggling with displaying a nice preview functionality with fzf i.e. trying to do something like
$ gh pr list | fzf --preview 'gh pr view {1}'
but as mentioned here, the display in preview isn't very pretty.

@mislav you mentioned

We aim to enable the fzf usage as you are describing in a future release ✨

Any more details on that? Should I open a new issue?

I had no idea fzf could that. That's pretty awesome. This will be the way I look at PRs moving forward.

fzf protip using GH_FORCE_TTY:

GH_FORCE_TTY='50%' gh pr list | fzf --ansi --header-lines 3 \
  --preview 'GH_FORCE_TTY=$FZF_PREVIEW_COLUMNS gh pr view {1}'

Wow cool, is there a way to combine that with checkout so that when you press enter on one it gets checked out?

@timja

@timja Of course! Anything is possible. The fzf tool will print out the line that was selected when pressing Enter; you can then feed that line into any other program. For example, the mislav/gh-branch extension uses fzf to checkout the selected branch https://github.com/mislav/gh-branch/blob/fd4f3de8253040e865712f287eadb0022471a759/gh-branch#L102-L111

Thanks! Installed it, not quite what I was after but gives me enough to build my own
❤️

@mislav

Hmmmmm @mislav this should give a "richer" output of the the PR than what you've attached in the screenshot. The issue view seems OK though.

Compare:

GH_FORCE_TTY='50%' gh pr list | fzf --ansi --header-lines 3 --preview 'GH_FORCE_TTY=$FZF_PREVIEW_COLUMNS gh pr view {1}'

with:

GH_FORCE_TTY='50%' gh issue list | fzf --ansi --header-lines 3 --preview 'GH_FORCE_TTY=$FZF_PREVIEW_COLUMNS gh issue view {1}'

I'm on gh version 2.1.0 (2021-10-14) BTW. I can open a separate issue if you want.

Sorry to comment on an old issue, but I couldn't find a single up-to-date place with instuctions for using gh for light background terminal users. Some of the discussion above is about colors in rendered markdown. It's still the case today that markdown rendered by commands such as gh pr view uses grey text that's not readable against a white terminal background, and it isn't obvious from gh documentation how to fix this. gh config set accessible_colors enabled merely changes it to use the terminal's default white color (37) which isn't the solution.

However, setting the underlying markdown rendering library to use its light theme fixes it: GLAMOUR_STYLE=light

Navigation Menu

Repository navigation

More nuanced color support #364

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

More nuanced color support #364

Description

Activity

joshtriplett commented on Feb 12, 2020

zapo commented on Feb 19, 2020

mislav commented on Feb 19, 2020

limzykenneth commented on Feb 29, 2020

trych commented on Mar 6, 2020

juanibiapina commented on Mar 27, 2020

doi-t commented on Apr 24, 2020

Schahen commented on May 27, 2020

vilmibm commented on May 27, 2020

keysmashes commented on Jun 8, 2020

vilmibm commented on Jun 9, 2020

benknoble commented on Jul 18, 2020

auouymous commented on Jul 19, 2020

mislav commented on Jul 21, 2020

fmcgough commented on Sep 3, 2020

mislav commented on Sep 16, 2020

doi-t commented on Sep 21, 2020

slafs commented on Jul 14, 2021

vilmibm commented on Jul 15, 2021

enmanuelr commented on Oct 19, 2021

mislav commented on Oct 20, 2021

timja commented on Oct 20, 2021

mislav commented on Oct 20, 2021

timja commented on Oct 20, 2021

slafs commented on Oct 20, 2021

dandavison commented on Jan 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions