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

Bright foreground color hard-coded to be brightWhite, bold text invisible for light color schemes #3781

Closed
roblillack opened this issue Nov 29, 2019 · 3 comments
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@roblillack
Copy link

Environment

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

Steps to reproduce

  1. Select light color scheme (dark foreground color on very light background color)
  2. Try to display bright text (ANSI escape code [1m) without specifying a non-default color, for example by running this in a WSL shell:
echo "this is $(tput bold)normal bright text$(tput sgr0) and this is $(tput setaf 1)$(tput bold)red bright text$(tput sgr0)."

Expected behavior

The words "normal bright text" should be visible (and, preferably, highlighted in some way or bold).

Actual behavior

Windows Terminal selects "bright white" as the default "bright foreground" color which in this case is the same as the background color. Also, compare it to the behavior of ConEmu below, that works:

image

Suggestion

There are multiple ways to solve this problem (which are separate from implementing bold support as discussed in #109):

  1. Add an option brightForeground to the color schemes so light schemes can set it to a dark color, or
  2. Add an option to ignore the [1m escape sequences altogether, or
  3. Implement a better algorithm that does not hardcode using "bright white" but chooses a fitting color from the palette based on the perceived "darkness" of the background color (say, go with "bright black" for light backgrounds, "bright white" for dark backgrounds)

I strongly suggest to go with option no. 1.

@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 Nov 29, 2019
@j4james
Copy link
Collaborator

j4james commented Nov 29, 2019

This sounds the same as #3022, which was resolved as a duplicate of #2661 and #293.

@DHowett-MSFT
Copy link
Contributor

Yep, this is a /dupe of #2661 and #293. Thanks!

@ghost
Copy link

ghost commented Nov 30, 2019

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 Nov 30, 2019
@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 Nov 30, 2019
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

3 participants