starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 07:54:35 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Something is, well, probably fine with One half light #19982

New Issue
Open
opened 2026-01-31 06:59:28 +00:00 by claunia · 14 comments
claunia commented 2026-01-31 06:59:28 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (May 26, 2023).

From a mail thread with @jazzdelightsme and @oldnewthing

image

Repro:

  1. set theme for cmd to “One Half Light”
  2. set the “automatically adjust lightness” feature to “always”
  3. open a new cmd tab
  4. run “pwsh” or “powershell”
  5. run “Get-PSReadLineOption”, and notice that several of the colors are invisible (notably the DefaultTokenColor).

This is Terminal 1.18, with One Half Light. I’ve typed git do the thing.
image

Left: "adjustIndistinguishableColors": "never",
right: "adjustIndistinguishableColors": "always",

wait, what’s going on here?

image

And the output of conpty looks pretty normal, too. After typing the o in git do, Terminal gets:
␛[?25l␛[93m␛[36;27Hgit␣␛[37mdo␣␣␛[36;33H␛[?25h␛[m

Which is basically:
• Turn cursor off
• Use bright yellow FG
• Cursor to the start of the prompt
• “git “
• Use dark white FG
• “do “ (two spaces)
• Move the cursor back a space, turn it back on, and reset the colors.

Which is exactly what I’d expect. So why is that appearing as white, and not black (which is what bright white is defined as) from the scheme?

Maybe I haven’t had enough coffee yet this morning.

Trawling through the colortool output, I noticed:

1;36m␛[38;5;14m␛[3C␣␣gYw␣␣␣␣␣gYw␣␣␣␛[48;5;1m␣␣gYw␣␣␛[49m␣␛[48;5;2m␣␣gYw␣␣␛[49m␣␛[48;5;3m␣␣gYw␣␣␛[49m␣␛[48;5;4m␣␣gYw␣␣␛[49m␣␛[?25l␛[m␛[38;5;14m␛[48;5;5m␣␣gYw␣␣␛[49m␣␛[48;5;6m␣␣gYw␣␣␛[49m␣␛[48;5;7m␣␣gYw␣␣␛[m␍␊

37m␛[5C␣␣gYw␣␣␣␣␣gYw␣␣␣␛[48;5;1m␣␣gYw␣␣␛[m␣␛[48;5;2m␣␣gYw␣␣␛[m␣␛[48;5;3m␣␣gYw␣␣␛[m␣␛[48;5;4m␣␣gYw␣␣␛[m␣␛[48;5;5m␣␣gYw␣␣␛[m␣␛[48;5;6m␣␣gYw␣␣␛[m␣␛[48;5;7m␣␣gYw␣␣␛[m␍␊

1;37m␛[38;5;15m␛[3C␣␣gYw␣␣␣␣␣gYw␣␣␣␛[48;5;1m␣␣gYw␣␣␛[49m␣␛[48;5;2m␣␣gYw␣␣␛[49m␣␛[48;5;3m␣␣gYw␣␣␛[49m␣␛[48;5;4m␣␣gYw␣␣␛[49m␣␛[48;5;5m␣␣gYw␣␣␛[49m␣␛[48;5;6m␣␣gYw␣␣␛[49m␣␛[48;5;7m␣␣gYw␣␣␛[21;1H␛]0;OHL,␣no␣adjust␇␛[?25h␛[m␛[30m␛[107m␍␊
  • the 37m line doesn't actually set the foreground color - I think it's relying on the 7 == "default index" thing.
  • we're emitting all the colors as 256 color indicies?? good god

Maybe this is related to #15408

Originally created by @zadjii-msft on GitHub (May 26, 2023). From a mail thread with @jazzdelightsme and @oldnewthing ![image](https://github.com/microsoft/terminal/assets/18356694/62d3195a-95ec-418d-874a-d7391cb7b198) > > Repro: > 1. set theme for cmd to “One Half Light” > 2. set the “automatically adjust lightness” feature to “always” > 3. open a new cmd tab > 4. run “pwsh” or “powershell” > 5. run “Get-PSReadLineOption”, and notice that several of the colors are invisible (notably the DefaultTokenColor). --- This is Terminal 1.18, with One Half Light. I’ve typed `git do the thing`. ![image](https://github.com/microsoft/terminal/assets/18356694/6ea37c3c-f131-4d9b-80dc-1d066d1800ae) Left: `"adjustIndistinguishableColors": "never", ` right: `"adjustIndistinguishableColors": "always", ` wait, what’s going on here? ![image](https://github.com/microsoft/terminal/assets/18356694/ff7d104b-cb24-43f4-a7fe-7d5864a770da) And the output of conpty looks pretty normal, too. After typing the `o` in `git do`, Terminal gets: `␛[?25l␛[93m␛[36;27Hgit␣␛[37mdo␣␣␛[36;33H␛[?25h␛[m` Which is basically: • Turn cursor off • Use bright yellow FG • Cursor to the start of the prompt • “git “ • Use dark white FG • “do “ (two spaces) • Move the cursor back a space, turn it back on, and reset the colors. Which is exactly what I’d expect. So why is that appearing as white, and not black (which is what bright white is defined as) from the scheme? Maybe I haven’t had enough coffee yet this morning. ---- Trawling through the colortool output, I noticed: ``` 1;36m␛[38;5;14m␛[3C␣␣gYw␣␣␣␣␣gYw␣␣␣␛[48;5;1m␣␣gYw␣␣␛[49m␣␛[48;5;2m␣␣gYw␣␣␛[49m␣␛[48;5;3m␣␣gYw␣␣␛[49m␣␛[48;5;4m␣␣gYw␣␣␛[49m␣␛[?25l␛[m␛[38;5;14m␛[48;5;5m␣␣gYw␣␣␛[49m␣␛[48;5;6m␣␣gYw␣␣␛[49m␣␛[48;5;7m␣␣gYw␣␣␛[m␍␊ 37m␛[5C␣␣gYw␣␣␣␣␣gYw␣␣␣␛[48;5;1m␣␣gYw␣␣␛[m␣␛[48;5;2m␣␣gYw␣␣␛[m␣␛[48;5;3m␣␣gYw␣␣␛[m␣␛[48;5;4m␣␣gYw␣␣␛[m␣␛[48;5;5m␣␣gYw␣␣␛[m␣␛[48;5;6m␣␣gYw␣␣␛[m␣␛[48;5;7m␣␣gYw␣␣␛[m␍␊ 1;37m␛[38;5;15m␛[3C␣␣gYw␣␣␣␣␣gYw␣␣␣␛[48;5;1m␣␣gYw␣␣␛[49m␣␛[48;5;2m␣␣gYw␣␣␛[49m␣␛[48;5;3m␣␣gYw␣␣␛[49m␣␛[48;5;4m␣␣gYw␣␣␛[49m␣␛[48;5;5m␣␣gYw␣␣␛[49m␣␛[48;5;6m␣␣gYw␣␣␛[49m␣␛[48;5;7m␣␣gYw␣␣␛[21;1H␛]0;OHL,␣no␣adjust␇␛[?25h␛[m␛[30m␛[107m␍␊ ``` * the `37m` line doesn't actually set the foreground color - I think it's relying on the `7` == "default index" thing. * we're emitting all the colors as 256 color indicies?? good god Maybe this is related to #15408
claunia added the Area-RenderingIssue-BugProduct-Terminal labels 2026-01-31 06:59:28 +00:00
claunia commented 2026-01-31 06:59:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 26, 2023):

I knew I hadn't had enough coffee:

image

My version of ColorTool is wrong here - dark white in One Half Light is white. Colortool is doing the "oh yea sure dark white is just the default color" thing cause it was written for the Console API.

Configuring a light colored theme from the powershell docs is probably the solution here

@zadjii-msft commented on GitHub (May 26, 2023): I knew I hadn't had enough coffee: ![image](https://github.com/microsoft/terminal/assets/18356694/0feb7ea5-1bc1-4565-a173-609e05e3b175) My version of ColorTool is wrong here - dark white in One Half Light _is_ white. Colortool is doing the "oh yea sure dark white is just the default color" thing cause it was written for the Console API. [Configuring a light colored theme](https://learn.microsoft.com/en-us/powershell/scripting/learn/shell/using-light-theme?view=powershell-7.3) from the powershell docs is probably the solution here
claunia commented 2026-01-31 06:59:29 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 26, 2023):

If PSReadLine implicitly assumes that "white" = white and "black" = black, why doesn't it implicitly assume that the default foreground "`e[39m" is equivalent to white "`e[37m"? In other words: Should it use "`e[39m"? While it would be a slight regression for a theme light Solarized Dark, it would fix the general issue fairly consistently in combination with color nudging/contrasting.

It can be hot fixed by adding this to profile.ps1:

Set-PSReadLineOption -Colors @{
    ContinuationPrompt = "`e[39m"
    Default = "`e[39m"
    Type = "`e[39m"
}

and enabling Defaults > Appearance > Automatically adjust brightness of indistinguishable text in 1.18.

@lhecker commented on GitHub (May 26, 2023): If PSReadLine implicitly assumes that "white" = white and "black" = black, why doesn't it implicitly assume that the default foreground ``"`e[39m"`` is equivalent to white ``"`e[37m"``? In other words: Should it use ``"`e[39m"``? While it would be a slight regression for a theme light Solarized Dark, it would fix the general issue fairly consistently in combination with color nudging/contrasting. It can be hot fixed by adding this to `profile.ps1`: ```pwsh Set-PSReadLineOption -Colors @{ ContinuationPrompt = "`e[39m" Default = "`e[39m" Type = "`e[39m" } ``` and enabling `Defaults > Appearance > Automatically adjust brightness of indistinguishable text` in 1.18.
claunia commented 2026-01-31 06:59:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 26, 2023):

I mean, it probably should. https://github.com/MicrosoftDocs/PowerShell-Docs/issues/9358 was one of the earlier discussions. I forget why we came to the conclusion that couldn't be the default in PsReadline.

For reference:
3c3b1aac02/src/cascadia/TerminalSettingsModel/defaults.json (L172-L193)

Are we horrifically morally opposed to manually setting the white value to #fbfbfb instead of #fafafa, so that the auto adjust algorithm does something to it? It seems like a frequent enough footgun that a rgb(1,1,1) delta would be worth it. Even if it's not technically our problem, I think this is something in our power to fix

@zadjii-msft commented on GitHub (May 26, 2023): I mean, it probably should. https://github.com/MicrosoftDocs/PowerShell-Docs/issues/9358 was one of the earlier discussions. I forget why we came to the conclusion that _couldn't_ be the default in PsReadline. For reference: https://github.com/microsoft/terminal/blob/3c3b1aac02320f49f6887f08e6d6d1d56132b1ef/src/cascadia/TerminalSettingsModel/defaults.json#L172-L193 Are we horrifically morally opposed to manually setting the `white` value to `#fbfbfb` instead of `#fafafa`, so that the auto adjust algorithm does something to it? It seems like a frequent enough footgun that a rgb(1,1,1) delta would be worth it. Even if it's not _technically_ our problem, I think this is something in our power to fix
claunia commented 2026-01-31 06:59:29 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 26, 2023):

@j4james A long time ago you pointed out that we shouldn't adjust the contrast of colors when they're identical (like with the concealed attribute). Would this still work if we used a hardcoded 16 color index table that isn't influenced by the user's theme? 1 That way, when a light color scheme is used, we'd still consider \e[37m "white" to be a color that's different from the (white) background color and thus apply color contrasting to make it visible.

  1. I believe we could implement it without lookup table, if we map default-background to color index 0 and default foreground to index 7 for the comparison. There are probably some more clever ways it could be done. ↩︎

@lhecker commented on GitHub (May 26, 2023): @j4james A long time ago you pointed out that we shouldn't adjust the contrast of colors when they're identical (like with the concealed attribute). Would this still work if we used a hardcoded 16 color index table that isn't influenced by the user's theme? [^1] That way, when a light color scheme is used, we'd still consider `\e[37m` "white" to be a color that's different from the (white) background color and thus apply color contrasting to make it visible. [^1]: I believe we could implement it without lookup table, if we map default-background to color index 0 and default foreground to index 7 for the comparison. There are probably some more clever ways it could be done.
claunia commented 2026-01-31 06:59:29 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 26, 2023):

I think there's value in separating out the "conceal" vs "colors are the same" cases. We no longer have to act like the only data we have at the point of color selection is the raw values of foreground and background (thanks to James fixing #2661), so we could totally understand this case1 separately from the same color case.

Now, I really do wonder how many applications meaningfully display actual text in the same foreground as background (rather than spaces or whatever) and why on earth they're doing that 😄

  1. we should also skip rendering concealed sections entirely; why waste time shaping and rasterizing and blitting? ↩︎

@DHowett commented on GitHub (May 26, 2023): I think there's value in separating out the "conceal" vs "colors are the same" cases. We no longer have to act like the only data we have at the point of color selection is the raw values of foreground and background (thanks to James fixing #2661), so we could totally understand this case[^1] separately from the same color case. Now, I really do wonder how many applications _meaningfully_ display actual text in the same foreground as background (rather than spaces or whatever) and why on earth they're doing that :smile: [^1]: we should also skip rendering concealed sections entirely; why waste time shaping and rasterizing and blitting?
claunia commented 2026-01-31 06:59:30 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 26, 2023):

I really do wonder how many applications meaningfully display actual text in the same foreground as background

I'm not sure I've seen this in practice, but I can certainly think of hypothetical reasons for it. For example, you might write out content as black-on-black to hide spoilers, and then later reveal that content with DECCARA (i.e. change attributes in rectangular area). You could do the same sort of thing with the Win32 console APIs I think.

@j4james commented on GitHub (May 26, 2023): > I really do wonder how many applications _meaningfully_ display actual text in the same foreground as background I'm not sure I've seen this in practice, but I can certainly think of hypothetical reasons for it. For example, you might write out content as black-on-black to hide spoilers, and then later reveal that content with `DECCARA` (i.e. change attributes in rectangular area). You could do the same sort of thing with the Win32 console APIs I think.
claunia commented 2026-01-31 06:59:30 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 31, 2023):

We've been discussing this and felt like it'd be better to only conceal text if it has the conceal attribute - Even though we think you're actually completely right @j4james. 😅 It's just that only handling \e[8m exclusively is a bit more consistent with how other terminals work, but more importantly, it works correctly even if you accidentally set the fg/bg to the same color and is a lot easier to implement correctly.

@lhecker commented on GitHub (May 31, 2023): We've been discussing this and felt like it'd be better to only conceal text if it has the conceal attribute - Even though we think you're actually completely right @j4james. 😅 It's just that only handling `\e[8m` exclusively is a bit more consistent with how other terminals work, but more importantly, it works correctly even if you accidentally set the fg/bg to the same color and is a lot easier to implement correctly.
claunia commented 2026-01-31 06:59:30 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jun 1, 2023):

That's cool. I don't feel strongly about it, as long as it's not enabled by default.

Back when we were first discussing this feature, I had hoped we could get by with a very light adjustment - just enough to make the crap color schemes usable - and for that I thought it best to try and remain as "correct" as possible. But now it's clearly an accessibility feature with a very noticeable change. So I think if you're enabling the color adjustment now, you've got to expect that there could be edge cases where things may not look quite right.

@j4james commented on GitHub (Jun 1, 2023): That's cool. I don't feel strongly about it, as long as it's not enabled by default. Back when we were first discussing this feature, I had hoped we could get by with a very light adjustment - just enough to make the crap color schemes usable - and for that I thought it best to try and remain as "correct" as possible. But now it's clearly an accessibility feature with a very noticeable change. So I think if you're enabling the color adjustment now, you've got to expect that there could be edge cases where things may not look quite right.
claunia commented 2026-01-31 06:59:31 +00:00
Author
Owner
Copy Link

@citelao commented on GitHub (Jun 2, 2023):

I know I'm kinda blundering into a long-standing discussion, but I've been observing this conversation from the sidelines for a bit -

Is this an issue that affects basically every light theme across basically every terminal emulator?

In my experience, color schemes define ANSI colors like blue or bright red in the context of the background color: they're designed to be visible & sensible for the theme. I'd always assumed, then, that colors like black or white would also fall into this. In particular, since most terminals use a dark mode, I assumed that white is typically "foreground text color" and black is typically "background color."

So I'd expect a light-mode color scheme to actually lie: white would be a black color, to show up against the background, and black would be a white color, to match the background.

That isn't the case here, for any of the builtin themes: white is a literal white and black is a literal black, and I was prepared to point that out here. But then I investigated, and it seems like that's the case everywhere?

Terminal color What I thought it would mean What it means in dark mode What it means in light mode
White "foreground text color" literally white (happens to be foreground text color) literally white (happens to be invisible)
Black "background color" literally black (happens to be invisible) literally black (happens to be foreground text color)

So is this an issue that has affected every light theme across every terminal emulator that uses colors?

@citelao commented on GitHub (Jun 2, 2023): I know I'm kinda blundering into a long-standing discussion, but I've been observing this conversation from the sidelines for a bit - Is this an issue that affects **basically every light theme** across **basically every terminal emulator**? In my experience, color schemes define ANSI colors like `blue` or `bright red` in the context of the background color: they're designed to be visible & sensible for the theme. I'd always *assumed*, then, that colors like `black` or `white` would also fall into this. In particular, since most terminals use a dark mode, I assumed that `white` is typically "foreground text color" and `black` is typically "background color." So I'd *expect* a light-mode color scheme to actually *lie*: `white` would be a black color, to show up against the background, and `black` would be a white color, to match the background. That isn't the case here, for any of the builtin themes: `white` is a literal white and `black` is a literal black, and I was prepared to point that out here. But then I investigated, and it seems like that's the case everywhere? * [The official One Half repo](https://github.com/sonph/onehalf) defines `37m` as a literal white in both themes, `30m` as a literal black. * [Solarized](https://ethanschoonover.com/solarized/) ([random impl](https://github.com/altercation/solarized/blob/master/iterm2-colors-solarized/Solarized%20Light.itermcolors#L75)) seems to, too. |Terminal color|What I thought it would mean|What it means in dark mode|What it means in light mode| |-|-|-|-| |White|"foreground text color"|literally white (happens to be foreground text color)|literally white (happens to be invisible)| |Black|"background color"|literally black (happens to be invisible)|literally black (happens to be foreground text color)| So is this an issue that has affected **every light theme** across **every terminal emulator** that uses colors?
claunia commented 2026-01-31 06:59:31 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 2, 2023):

So is this an issue that has affected every light theme across every terminal emulator that uses colors?

It absolutely is! But there's some nuance.

There are two (occasionally three) additional colors in the standard color palette for compliant terminal emulators: foreground1 and background. Those are intended to be the ground truth: the user's preferred foreground and background. Almost all terminal emulators that ship light color schemes by default set their foregrounds to dark.

Those are the colors you see in the m row (unadorned, no attribute). They are also accessible via \e[39m (foreground) and \e[49m (background).

The issue arises when applications request ANSI white by name. It's arguably wrong to make that anything but white. PSReadline is in a weird position, where it is trying to bridge the gap between the Windows Console API2 and modern terminal emulation and color schemes. It doesn't always know that the palette is 18 colors (all 16 plus fg, bg)... and sometimes limits its choice to 16. That worked perfectly fine when the Windows Console only supported 16 😉.

  1. The occasional third is "bright foreground", which applies to \e[1m or \e[1;39m when SGR 1 is set to enable "bright" colors. It might also be accessible via \e[99m (AIX SGR), but that is wild speculation on my part. ↩︎

  2. SetConsoleTextAttribute only supports the 16-color palette of the Windows Console. ↩︎

@DHowett commented on GitHub (Jun 2, 2023): > So is this an issue that has affected every light theme across every terminal emulator that uses colors? It absolutely is! But there's some nuance. There are two (occasionally three) additional colors in the standard color palette for compliant terminal emulators: _foreground_[^1] and _background_. Those are intended to be the ground truth: the user's preferred foreground and background. Almost all terminal emulators that ship light color schemes by default set their _foregrounds_ to dark. Those are the colors you see in the `m` row (unadorned, no attribute). They are also accessible via `\e[39m` (foreground) and `\e[49m` (background). The issue arises when applications _request ANSI white by name._ It's arguably wrong to make that anything but white. PSReadline is in a weird position, where it is trying to bridge the gap between the Windows Console API[^2] and modern terminal emulation and color schemes. It doesn't always know that the palette is 18 colors (all 16 plus fg, bg)... and sometimes limits its choice to 16. That worked perfectly fine when the Windows Console only supported 16 😉. [^1]: The occasional third is "bright foreground", which applies to `\e[1m` or `\e[1;39m` when `SGR 1` is set to enable "bright" colors. It might also be accessible via `\e[99m` (AIX SGR), but that is wild speculation on my part. [^2]: `SetConsoleTextAttribute` only supports the 16-color palette of the Windows Console.
claunia commented 2026-01-31 06:59:32 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jun 3, 2023):

It's worth noting that some apps will try to detect whether you're using a light color scheme (by querying the palette values), and then adjust their colors appropriately. This is not yet supported in Windows Terminal though.

@j4james commented on GitHub (Jun 3, 2023): It's worth noting that some apps will try to detect whether you're using a light color scheme (by querying the palette values), and then adjust their colors appropriately. This is not yet supported in Windows Terminal though.
claunia commented 2026-01-31 06:59:32 +00:00
Author
Owner
Copy Link

@Ririshi commented on GitHub (Aug 6, 2023):

Can someone suggest a workaround for people who often switch between light and dark themes and schemes? I use AutoDarkMode to switch my Windows theme between dark and light based on time of day. I set up my WT to switch between a dark and light colour scheme (Material Darker and One Half Light), and I would like to be able to read all text in both modes. The two issues I'm running into are as follows:

  1. PSReadLine shows white text on a white background with default settings (as mentioned in this issue).

  2. On WSL with Ubuntu 22.04, some output from ls -al (with ls aliased to ls --colors=auto) is coloured white, because my ~/.dircolors contains this:

FILE 37 # regular file
MULTIHARDLINK 1;37 # regular file with more than one link

Apparently those lines are not default (they're not in the output of dircolors --print-database), but I cannot remember why I ever set them like that. Even without this, though, the PSReadLine issue still remains.

Both of these happen even when "adjustIndistinguishableColors": "always" is set, which does not seem to realise that white on white is unreadable? I'm probably missing something when it comes to how this option is implemented.

Regardless, is there something I can do in my WT setup that will fix (or work around) both issues? While individual workarounds (e.g. PSReadLine colour settings, and changing my ~/.dircolors) are fine for my personal setup, it will not fix invisible text when SSHing into other machines with similar setups.

Edit: for now I've used the hotfix suggested by lhecker, updating some PSReadLine colors to `e[39m, and updated my ~/.dircolors to remove the explicit white. I'm guessing it now implicitly uses regular foreground colours instead, which works fine.

Another edit: I've added Member and Number to PSReadLine hotfix list as well. For me, Member was also set to `e[39m, and Number was set to `e[97m, which is bright white.

Set-PSReadLineOption -Colors @{
    ContinuationPrompt = "`e[39m"
    Default            = "`e[39m"
    Type               = "`e[39m"
    Member             = "`e[39m"
    Number             = "`e[39m"
}
@Ririshi commented on GitHub (Aug 6, 2023): Can someone suggest a workaround for people who often switch between light and dark themes and schemes? I use AutoDarkMode to switch my Windows theme between dark and light based on time of day. I set up my WT to switch between a dark and light colour scheme (Material Darker and One Half Light), and I would like to be able to read all text in both modes. The two issues I'm running into are as follows: 1. PSReadLine shows white text on a white background with default settings (as mentioned in this issue). 2. On WSL with Ubuntu 22.04, some output from `ls -al` (with `ls` aliased to `ls --colors=auto`) is coloured white, because my `~/.dircolors` contains this: ``` FILE 37 # regular file MULTIHARDLINK 1;37 # regular file with more than one link ``` Apparently those lines are not default (they're not in the output of `dircolors --print-database`), but I cannot remember why I ever set them like that. Even without this, though, the PSReadLine issue still remains. Both of these happen even when `"adjustIndistinguishableColors": "always"` is set, ~~which does not seem to realise that white on white is unreadable? I'm probably missing something when it comes to how this option is implemented.~~ Regardless, is there something I can do in my WT setup that will fix (or work around) both issues? While individual workarounds (e.g. PSReadLine colour settings, and changing my `~/.dircolors`) are fine for my personal setup, it will not fix invisible text when SSHing into other machines with similar setups. Edit: for now I've used the hotfix suggested by lhecker, updating some PSReadLine colors to `` `e[39m ``, and updated my `~/.dircolors` to remove the explicit white. I'm guessing it now implicitly uses regular foreground colours instead, which works fine. Another edit: I've added `Member` and `Number` to PSReadLine hotfix list as well. For me, `Member` was also set to `` `e[39m ``, and `Number` was set to `` `e[97m ``, which is bright white. ```pwsh Set-PSReadLineOption -Colors @{ ContinuationPrompt = "`e[39m" Default = "`e[39m" Type = "`e[39m" Member = "`e[39m" Number = "`e[39m" } ```
claunia commented 2026-01-31 06:59:32 +00:00
Author
Owner
Copy Link

@itayking1990 commented on GitHub (Mar 19, 2024):

I face the same issue with light mode & one half light any eta for this bug?

Moreover, could someone explain where exactly to put this:

Set-PSReadLineOption -Colors @{
    ContinuationPrompt = "`e[39m"
    Default            = "`e[39m"
    Type               = "`e[39m"
    Member             = "`e[39m"
    Number             = "`e[39m"
}

I tried to $Profile.CurrentUserCurrentHost

But I can not find the profile.ps1 file (I have a new pc with a fresh install of Windows 11 latest stable build)

@itayking1990 commented on GitHub (Mar 19, 2024): I face the same issue with light mode & one half light any eta for this bug? Moreover, could someone explain where exactly to put this: ``` Set-PSReadLineOption -Colors @{ ContinuationPrompt = "`e[39m" Default = "`e[39m" Type = "`e[39m" Member = "`e[39m" Number = "`e[39m" } ``` I tried to $Profile.CurrentUserCurrentHost But I can not find the profile.ps1 file (I have a new pc with a fresh install of Windows 11 latest stable build)
claunia commented 2026-01-31 06:59:33 +00:00
Author
Owner
Copy Link

@jazzdelightsme commented on GitHub (Mar 19, 2024):

@itayasaf2002xd

I can not find the profile.ps1 file

It does not exist by default (it is optional, for user customizations).

Note that legacy powershell.exe (5.1) and modern pwsh.exe each have separate $profile scripts (most people I know do something to "unify" them--either they both dot-source a common script, or one is a link to the other, something like that).

@jazzdelightsme commented on GitHub (Mar 19, 2024): @itayasaf2002xd > I can not find the profile.ps1 file It does not exist by default (it is optional, for user customizations). Note that legacy `powershell.exe` (5.1) and modern `pwsh.exe` each have separate `$profile` scripts (most people I know do something to "unify" them--either they both dot-source a common script, or one is a link to the other, something like that).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Rendering Issue-Bug Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#19982
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?