Support 0xRRGGBB colors on Write-Host

[Jaykul]

Summary of the new feature / enhancement

As a user I want Write-Host to support specifying full RGB colors on the -Foreground and -Background parameters.

I would also like to be able to specify any of the X11 named colors by name

Proposed technical implementation details (optional)

Instead of needing to write $($PSStyle.Foreground.FromRgb(0xa020f0)) into the string to set a purple color, I want to specify -Foreground A020F0 or -Foreground 0xa020f0 or -Foreground Purple

[doctordns]

If you do accept an Ansi colour, can you also accept a named colour (eg "darkred")?

[SeeminglyScience]

I think it's worth discussing from an implementation stand point how this would change HostInformationMessage. I think there are a few options.

1. Make a new object similar to HostInformationMessage but specific to rich color
2. Add new string properties to HostInformationMessage for prefix and suffix escape sequences
3. Add new int properties to HostInformationMessage and allow the host to translate it (since while uncommon, GUI hosts do exist)
4. Just put the escape sequences into HostInformationMessage.Message

[Jaykul]

I think it's worth discussing from an implementation stand point how this would change HostInformationMessage. I think there are a few options.

There was some discussion of this years ago on #2381 and I still like the idea of adding objects like RGBColor and Text.

Of course, the current implementation is spaghetti. E.g. $PSStyle.OutputRendering ="PlainText" will strip all VT escape sequences -- NOT hust the ones PowerShell adds, and NOT just colors. I really hate that PowerShell is stripping escape sequences from the output of other things, However, it doesn't strip colors added by Write-Host. If we changed Write-Host so it uses escape sequences, it would then be affected by OutputRendering = "PlainText" ...

[jdhitsolutions]

Added to the Cmdlet Working Group list for review and consideration.

[jhoneill]

I really hate that PowerShell is stripping escape sequences from the output of other things, However, it doesn't strip colors added by Write-Host. If we changed Write-Host so it uses escape sequences, it would then be affected by OutputRendering = "PlainText" ...

@Jaykul
Things like git log and git diff still output with colour - which I'm fairly sure is ansi - do you mean PowerShell itself is stripping sequences from functions / cmdlets which aren't part of the core package ?

It's a "what do users expect ? " question. If I say I want plaintext rendering , what's the scope of that ?
The rendering of Error, verbose etc is now done with ANSI. so the plain-text option displays them plain, but Write-Host keeps whatever its parameters specify (ANSI sequences in the text to be written are blocked). That allows a developer to impose colours the user doesn't want and create accessibility problems so one question here is, Should the foreground and background in Write-Host also send ANSI ?

To the wider point:

• Each console host defines, via user settings, what R,G,B values to use for 16 colours (Black, White, RGB, YMC in Bright/Dark variants) people may remember Windows PowerShell redefining DarkMagenta in the console host for the PowerShell blue background. Different hosts have different defaults for these 16 - compare the output of $psStyle in VSCode and Windows Terminal.
• The 16 are embedded in [consoleColor] - unfortunately its naming of "Yellow"/"DarkYellow" is out-of step with the ANSI names "BrightYellow"/"Yellow".
• [system.drawing.color] supports most X11 named colours (some are missing) and defines what RGB values they should be. These don't include Bright/dark versions of everything and has some named "light" instead. So "Yellow" has ANSI, ConsoleColor and Drawing.Color meanings
• Write-host uses [consoleColor]. Any change needs to support the existing names and values. e.g. write-host -f 14 "This is Yellow" still needs to translate 14 to 'yellow' and yellow to mean whatever the brighter Yellow has been defined as, NOT an absolute 0xFFFF00

There's a choice betwen "add new parameters to write-host" or "Just use ANSI". I wrote and extension for [system.drawing.color] to accept text and wrap it in the ansi codes - see below - I'm sure it can be improved, but why wouldn't we go the "Just ansi" route ? Stopping users managing their colours isn't a good reason :-)

<?xml version="1.0" encoding="utf-8" ?>
<Types>
  <Type>
    <Name>System.Drawing.Color</Name>
    <Members>
      <ScriptMethod>
        <Name>Foreground</Name>
        <Script>
            param ($Text)
            ("$([char]27)[38;2;{0};{1};{2}m" -f $this.r, $this.g , $this.b ) + $Text.ToString() +"$([char]27)[0m"
        </Script>
      </ScriptMethod>
      <ScriptMethod>
        <Name>Background</Name>
        <Script>
            param ($Text)
            ("$([char]27)[48;2;{0};{1};{2}m" -f $this.r, $this.g , $this.b ) + $Text.ToString() +"$([char]27)[0m"
        </Script>
      </ScriptMethod>
    </Members>
  </Type>
</Types>

After doing Update-TypeData -AppendPath .\DrawingColor.Types.ps1xml It's called like this

using namespace 'System.Drawing'

[color]::yellow.Background( [Color]::Red.foreground("This is red"))

For nicer syntax. The following Allows foreground Gold "Always believe in your soul"

function foreground {
param(
[ArgumentCompleter({
    param ($CommandName, $ParameterName, $WordToComplete, $CommandAst, $FakeBoundParameters)
    [enum]::GetNames([System.Drawing.KnownColor]).where({$_ -like "$WordToComplete*"}) } ) ]
    [System.Drawing.Color]$Color,
    
    $Text 
)  
    $Color.Foreground($Text)
}

[Jaykul]

Things like git log and git diff still output with colour - which I'm fairly sure is ansi - do you mean PowerShell itself is stripping sequences from functions / cmdlets which aren't part of the core package ?

Just so, @Jhoneil yes.

For what it's worth, I think you're presenting a false choice between extending and compatibility. My PANSIES module's Write-Host already handles all the colors compatibly -- and a little more than you listed, because it handles the x11 palette (aka the web-safe color palette) by index ... or by name:

What it doesn't handle (because it's the "PowerShell ANSI Escape Sequences" module) is falling back to API calls when $PSStyle.OutputRendering = "PlainText" so that it can still output text in color, the way the the built-in Write-Host does when you ask for "Plain Text" output. As a result, PowerShell throws out it's color if you set "PlainText" rendering:

[jhoneill]

@Jaykul - It wasn't intentionally a false choice - you've found a workable to request a specific green.
We still have the problem of not being quite sure what "Green" will give, it RGB value 0-max-0? Or the 3rd of 16 defined colours for the terminal, or the 11th? (Which could be re-defined to something where the hue isn't green).

The key question is the user expectation one I posed above

If I say I want plaintext rendering , what's the scope of that ?
The rendering of Error, verbose etc is now done with ANSI, so the plain-text option displays them plain, but Write-Host keeps whatever its parameters specify (ANSI sequences in the text to be written are blocked). That allows a developer to impose colours the user doesn't want and create accessibility problems, so one question here is, Should the foreground and background in Write-Host also send ANSI ?

The initial question about plaintext stopping your code from displaying formatting... if I want it that way, and plaintext doesn't do it, how do I get what I want? Because currently one method works for all ansi - I haven't checked if setting NO_COLOR turns off colours in Write-Host.

With write-host and basic ansi colours using the Palette of 16 if the user has changed the palette for accessibility or any other reason it's reasonable to assume cyan will display OK, even if it is some other colour. That's a dangerous assumption if you pick X11 Teal. So I think it's good practice to specify absolute colours in anything someone else will use.

[Jaykul]

I feel like you're arguing a completely different issue, without bothering to do a basic check of your assumptions, @jhoneill

You said that "currently, one method works for all ansi" -- but the fact is it only works on output that goes through the PowerShell text pipeline for output. There is no way to globally disable color in PowerShell, since Write-Host isn't affected by $PSStyle.OutputRendering. There is no way to disable color in the terminal either, that's why git log (and it's pagers) and PSReadLine still output color, even when you set OutputRendering ...

Like I said, the current implementation is spaghetti. I guess you need the terminal to handle ignoring colors, if you want black and white.

I still don't understand why we're talking about that

I'm not proposing to change color rendering (at least, I'm not in this issue). That's irrelevant to the question of whether we should allow more color options on the Write-Host command. 😣

Also, for what it's worth: I don't think sticking to the basic palette helps much if half your users are on PS5 with a "dark magenta" that's actually blue, and a "yellow" that's off-white. Most of the colors in PowerShell's base 16 are very hard to read on that blue background. Having access to the full color RGB mode doesn't help a lot if you can't tell what the background color is -- cyan's practically impossible to read on a white background....

[jhoneill]

I feel like you're arguing a completely different issue, without bothering to do a basic check of your assumptions, @jhoneill

Ouch.
It wouldn't be the first time I have gone off at a tangent, but I'm trying to check some assumptions here. Because (a) I would leave Write-Host frozen in its present state (b) I think when developers make use of colour they do so badly more often than not (c) Specifying absolute r,g,b colours without knowing what other colours are in use will lead to problems. Taking these three if I go into a working group session to talk about doing this my initial assumption is doing it is a poor use of resource. BUT I'm looking to be persuaded otherwise.

I started by saying

Things like git log and git diff still output with colour - which I'm fairly sure is ansi -

So

You said that "currently, one method works for all ansi" -

Yes, yes, all being "all generated entirely within PowerShell".

the current implementation is spaghetti.

It is, and I'm also trying to get a clear picture of where we should get to.

1. Should ANSI codes be removed from output of external .EXEs ?
2. Should Write-Host switch to using ANSI? Is there a valid reason for preventing a user turning off its colour rendering ?
3. And linked to 2 should Write-Host support absolute colours ?

Right now the answer is "use ANSI" for anything where the combination of basic palette and Write-host -foreground / -background isn't suitable.
As far as I can see this request is to allow output to be forced in colour when the user has expressed a preference (not fully observed) for none, and I'm not seeing how that's a good thing.