Terminal: Documentation update: explain the color names and how they related to ECMA-48

[kojoru]

Description of the new feature/enhancement

Currently colors in the config are names in what arguably is a somewhat confusing way. E. g. it's not immediately obvious what "BrightBlack" or "BrightWhite" actually is.

It's also not clear if those names are consistent with any other public color names?

Proposed technical implementation details

Can we reuse .NET's ConsoleColor enum instead?
https://docs.microsoft.com/en-us/dotnet/api/system.consolecolor?view=netframework-4.8

It's already used in .NET and powershell, and is widely known.

[j4james]

I assume the names are mostly based on the ANSI ECMA-48 standard (you can see the colors listed on Wikipedia) except they're using _purple_ instead of _magenta_. And while the standard only defined 8 colors, the _increased intensity_ attribute was often used to produce brighter versions of each of them, hence the _BrightXXX_ variants.

And even if you think the .NET names are better, they couldn't really change them now without causing every existing config to break (under the existing scheme, _Blue_ defines the dark shade of blue, but with .NET names, it would be defining the bright shade).

[DHowett-MSFT]

I miss the days when we simply had an indexed array of the first 16 ECMA-48 colors. ☹️

[WSLUser]

I think we should re-use in addition to any extra colors we have.

without causing every existing config to break

That is the only problem. We'll need a script to modify the existing config after Terminal is updated. New installs won't require it.

[ExE-Boss]

I think we should do this while Windows Terminal is still in the preview 0.x version, which allows (and expects) breaking changes according to semantic versioning.

[zadjii-msft]

Honestly, I kinda like the Red/BrightRed pairings more than the DarkRed/Red pairings. @j4james is correct that we were trying to follow the ANSI standard. Either one we pick is going to result in some subset of the population unhappy with our choice here.

We _definitely_ shouldn't be using "purple" as a color name, that was definitely an oversight. That should be magenta.

[WSLUser]

Can't we have both? We can still stick to ANSI standard while providing the Dark options in addition.

[kojoru]

The original reason for this issue was my genuine confusion over what BrightWhite and BrightBlack actually means when I first opened the config.

Those terms are pretty much ungoogleable until you know what you're looking for. I doubt that terminology is known outside of the circle of people who are actually working on implementing console-related stuff.

Not having any confusing names in it is the main reason I think ConsoleColor enum is objectively better, beyond simply bikeshedding.

But if you decide otherwise, at least the issue calls for more documentation. I imagine something like a table explaining different ways of naming colors for consoles that's easily available for someone editing the colors.

[DHowett-MSFT]

We're probably not going to make changes to the _names_ of the colors we support (withholding possible updates for purple->magenta), but we're happy to document why the brights are they way they are. Sorry for the confusion!

[craigbarnes]

I miss the days when we simply had an indexed array of the first 16 ECMA-48 colors

But ECMA-48 only specifies 8 colors...

[DHowett-MSFT]

Yes, you have me on a technicality.