Color differences between Command Prompt and Powershell terminals

[chhackett]

It was noted in Issue #11 that some brick apps display different colors for background/foreground in Command Prompt vs Powershell terminals. The command prompt window displays colors correctly.

I was able to see this by running the brick theme demo in the two shells.

Theme 1:

Theme 2:

[ShrykeWindgrace]

I tried running this demo via stack exec -- brick-theme-demo in different environments.

• pwsh from within WindowsTerminal - screen reset is off (screen remained blue instead of my shade of black, cursor positioning is all over the place, misplaced hints from psreadline, etc. Most importantly it broke my vim). A full reset of the terminal (write-Host "`ec") fixed colors and cursor, but vim still was bugged in that window.
• cmd from within WindowsTerminal - screen reset is off, I see app's text. Did not test vim.
• standalone powershell (in conhost, without much customization) - screen reset is off, prompt retains theme color (I guess pwsh would have had this problem, too, but it had a custom prompt with hardcoded colors)
• standalone cmd - same as above.

I used

  -brick-master
  - vty-windows-0.1.0.3
  - vty-crossplatform-0.1.0.0
  - vty-6.0

[ShrykeWindgrace]

I also ran stack exec -- vty-interactive-terminal-test in a standalone (aka conhost) window with powershell

As you see, magenta is not there at all, plus there are artifacts (asterisks). As if our code for magenta sent a sequence "text is transparent" =) Joke aside, that's strange that this problem showed up only in powershell and only in conhost - pwsh is ok in that regard.

[chhackett]

So I believe the problem with getting the right colors in powershell is that the powershell color palette is not the same as cmd color palette. That's obvious as soon as you open the window, with the blue background vs the black background in cmd.

My plan right now is to change how color is rendered. Instead of sending the default asci sequences, I will have the code output the RGB sequence for colors. Then, I believe the terminal will render it exactly as we expect it to.

I'll try to get that done this weekend.

ps. An alternative is to remap the color palette. But that seems like a bad idea, because then we have to reset it on shutdown... It looks complicated and fraught with peril.

btw, i discovered this: https://github.com/microsoft/terminal/blob/71c75561e5df3db53cfe6f9da1173a46441b99ed/src/tools/ansi-color/ansi-color.cmd

Makes it easy to see how all SGR colors and styles get rendered.

Here's a snippet of the output in cmd vs powershell:

[ShrykeWindgrace]

Most (or maybe all 😀) of my problems with terminal resets were solved by jtdaugherty/brick@b8c7afc, thanks @jtdaugherty!

[jtdaugherty]

Glad to hear it, @ShrykeWindgrace!

@chhackett for what it's worth, to some extent I think it might be best to make Vty's 16-color data type map to the terminal palette. That's what happens on Unix, and while it does mean that you're out of luck if the terminal's palette entries map to a wildly different set of colors than their color names would suggest, it does mean that the user has control over the color palette. If you make the 16-color entries in Vty map to true RGB colors, then you've lost the ability to tell Vty applications to use whatever colors the terminal is using. Maybe that's alright on Windows, I don't know. But in practical terms it means that if the user wants to use, say, Solarized in general, then an application that uses Vty on Windows will ignore the Solarized palette. The user might not want that, even if using Solarized results in a terrible UI in that application.

[jtdaugherty]

(But if you map Vty's 16 base colors to the terminal palette, that does mean application developers need to be even more aware that their initial color choices could give undesirable results. But if that's true, then the developers get to choose whether to just use RGB colors in their applications if it matters that much to them.)

[chhackett]

@jtdaugherty @ShrykeWindgrace
Yeah, I was going to run that question by you, as you've had much more experience with this than I have.

So I guess in general, the 16 color escape sequences will map to some color palette that can be tailored by users,
but if an application developer really wants to specify RGB values they can do that.

Which leaves me just wondering if I should close this bug as 'user error'?

I might leave this open for a little while as a place to document any other weird text styling issues. I'm not 100% confident we've worked out all those problems.

Any thoughts?

[jtdaugherty]

I guess if this really is just a matter of "default colors in some windows terminals aren't consistent with the conventions for the 16-color palette entries" rather than any actual bugs in vty-windows, then I suppose this could just be considered an unfortunate situation rather than a bug to be fixed. Maybe that means that for vty-windows, this is worth highlighting in an FAQ entry or something with a recommendation to use RGB colors if someone is concerned about color portabillity.

[jtdaugherty]

Another possibility that I'm thinking about because I have no idea how Windows terminals work is that maybe they just scrambled the palette entries, and some entries still do consistently provide certain colors but they just don't use the same palette slots as Unix-based terminals do. Like, if slot 3 is always yellow on Unix (say) but yellow is more commonly found in slot 7 on Windows, then this could just be a matter of remapping the Vty color names to the right palette slots rather than hoping that the palette will have the same structure as it does on Unix. But if this isn't true -- if the Windows palettes just aren't providing the right colors because the default themes deviated from those a lot -- then we're back to "use RGB colors" as a recommendation.

[jtdaugherty]

In fact I wonder if the outcome here also deserves some mention in the docs for vty-crossplatform as a portability note.

[ShrykeWindgrace]

It is worth mentioning that if Windows Terminal is installed, one can set is as a default emulator:
Start menu > Terminal > Choose the default terminal app... > select Windows Terminal. I think this is a perfectly valid recommendation, since MS insists (repeatedly!) that Windows Console Host (aka conhost) is very much legacy that they are not planning to develop.

and

[ShrykeWindgrace]

In the case at hand, it seems that with my almost default settings in powershell and conhost, magenta suddenly became equal to current bg (which nowhere near this color, it became some shade of blue) and yellow became equal to current fg (again, not yellow, a shade of white).

I do not quite see how we can detect the palette modifications or what was chosen as default bg/fg colors, so I agree that it should be treated as a user config not an issue but an unfortunate coincidence. I'd add two points in the FAQ about missing/invisible colors, something along the following:

• if you still have to/prefer to use "Windows console host" aka "conhost", then beware that colors in the 16-color palette might be remapped by your system config (or become "invisible") and if you care about exact rendering please use RGB instead.
• if you can, set "Windows Terminal" as your default engine for you CLI apps (here are the installation instructions and a setting to tweak); it has more sensible defaults and supports more features.

[chhackett]

I don't believe there is any way for vty-windows to address color differences in the different terminals. That is something that a user would have to manage by configuring the terminal itself. So I am going to close this issue.