blackBright is mentioned in README but is not implemented about ansi-styles

[adalinesimonian]

Also, you might want to commit the same fix you made here on chalk/chalk - it has the same exact text in the readme. 👍

[Qix-]

Black bright is actually it's own color believe it or not. On Windows there are four greyscale shades.

I'll take a look :)

[adalinesimonian]

Had no idea. Please, by all means, take a look.

Side note: I spent last night trying to get black on yellow to show up nicely on Windows... I wish I could have that time back.

[Qix-]

What did you try? Are you using chalk or consuming ansi-styles directly?

[adalinesimonian]

I was using chalk. Even with rgb(0,0,0) I'd get a weird grey-ish hue instead of full black.

Then I made it blue on yellow, and it was legible with both default colours and base16-tomorrow. Go figure!

[Qix-]

@vsimonian So even with rgb(0, 0, 0) depending on your windows version, that's just going to get encoded down to black 😅. If you're on windows 10, that might be a different story though.

As for the colors in the terminal, if black (rgb(0, 0, 0)) isn't showing up as actual black, it's almost certainly being encoded down to one of the more basic codes.

Which terminal are you using?

[adalinesimonian]

Yes, Windows 10. I was just trying everything out of desperation. Probably went through every combination of black or black-ish you could think of. Still possible I missed something; I was pretty frustrated!

It works now and I'm afraid to touch it.

[Qix-]

Is this cmd.exe or some other terminal that you're using? (I know the ticket is closed but I'm still interested in figuring out why it didn't show up as black for you :))

Also thanks for the report. gray is considered blackBright (which are both 90 in this case).

[adalinesimonian]

Aha, I said it was gray! (C'mon, had to boast a little bit.)

About the colours, I tried everything I could think of: cmd.exe, WSL running in the default Windows command-line shell, WSL running in MinTTY, and VSCode's integrated terminal. All of them were more than happy to give me a disgusting grey instead of black.

I thought it might be artefacts from the font-smoothing mudding up the black text, so I blew up the text size but to no avail. Everything I tried seemed to be entirely inconsistent across terminals, and the one that was legible in all was just using blue on orange with a fallback to a yellow background if there was no 256-bit colour support.

I dug up the code, here it is:

// cli-tags.js

const chalk = require('chalk')

module.exports = {
  /** [ERROR] */
  error: chalk.supportsColor
    ? chalk.bgRed.whiteBright.bold(' ERROR ')
    : '[ERROR]',
  /** [WARNING] */
  warning: chalk.supportsColor                       // this here
    ? (chalk.level > 1                               // is the reason
      ? chalk.bgYellow.bgKeyword('orange').blue.bold // we can't have
      : chalk.bgYellow.blue.bold)(' WARNING ')       // nice things
    : '[WARNING]',
  /** [INFO] */
  info: chalk.supportsColor
    ? chalk.bgBlue.whiteBright.bold(' INFO ')
    : '[INFO]'
}

If you're wondering "why the hell is she using bgYellow.bgKeyword('orange') but then also just uses bgYellow on its own???", the answer is gross.

So on Windows 10 build 15063 (I can't speak for other versions of Windows), when level is 1, bgYellow.bgKeyword('orange') results in this ugly:

Just look at that sad grey. Ugly. So I check the level manually, and if it's 1, only pass through the yellow background.

Meanwhile, on the same system, it shows up as orange in MinTTY as expected.

However, with the first line, if you get rid of the bgYellow which seems to be totally redundant, you break the output in VSCode's integrated terminal, and it fails to display any background colour at all. I don't have a screenshot, but just imagine that warning label having a black background, just like the rest of the terminal.

I already have a headache.

[Qix-]

That's actually super weird. bgKeyword('orange') should be resolving down to yellow in theory within color-convert. keyword -> rgb -> ansi16 (for level 1).

[Qix-]

Just tested:

> cc.keyword.ansi16('orange')
93

Which is bright yellow (ansi-styles will add 10 to get the background code in this case). So maybe those terminals don't support bright codes? Very strange.

Just curious; what does the following show up as:

chalk.yellowBright.bgBlack.inverse(' WARNING ')

[adalinesimonian]

Here comes a looooong comment

• cmd.exe:
  
• ConHost/WSL:
  
• MinTTY/WSL:
  
• VSCode Integrated Terminal/bash.exe:
  
• VSCode Integrated Terminal/cmd.exe:
  

[Qix-]

What build of Windows 10 are you on?

Conhost doesn't surprise me at all. Don't use it if you want terminal colors IMO.

Anyway, you're right in that cmd.exe should be working.

EDIT: Also, thank you for taking the time to do all of these. It's really appreciated.

[adalinesimonian]

Version 1703, build 15063

And I agree ConHost is garbage needing of improvement. But I still need to account for users out of my control using ConHost; at the very least they should have legible text (and in this case, while ugly, it is at least still legible).

And don't go thanking me for spamming this issue with pictures - at this point I might as well just be venting. Thanks for looking into the darn thing!

What's interesting to me is that this inverse method actually got me full, solid black on the console whereas before it wasn't really working.

So here's what I put together:

const chalk = require('chalk')

const boldTags = {
  /** [ERROR] */
  error: chalk.supportsColor
    ? chalk.bgRed.whiteBright.bold(' ERROR ')
    : '[ERROR]',
  /** [WARNING] */
  warning: chalk.supportsColor
    ? (chalk.level > 1
      ? chalk.bgYellow.bgKeyword('orange').black.bold
      : chalk.bgYellow.black.bold)(' WARNING ')
    : '[WARNING]',
  /** [INFO] */
  info: chalk.supportsColor
    ? chalk.bgBlue.whiteBright.bold(' INFO ')
    : '[INFO]'
}

const inverseTags = {
  /** [ERROR] */
  error: chalk.supportsColor
    ? chalk.bgWhiteBright.red.inverse.bold(' ERROR ')
    : '[ERROR]',
  /** [WARNING] */
  warning: chalk.supportsColor
    ? (chalk.level > 1
      ? chalk.yellow.keyword('orange').bgBlack.inverse.bold
      : chalk.yellow.bgBlack.inverse.bold)(' WARNING ')
    : '[WARNING]',
  /** [INFO] */
  info: chalk.supportsColor
    ? chalk.blue.bgWhiteBright.inverse.bold(' INFO ')
    : '[INFO]'
}

console.log(`Regular tags:
${boldTags.error}
${boldTags.warning}
${boldTags.info}`)

console.log(`Inverse tags:
${inverseTags.error}
${inverseTags.warning}
${inverseTags.info}`)

And here are the results:

Using inverse makes the white-text tags look grey, less bold, and generally more reminiscent of a sad clown, but on the black-text tag it is an absolute masterpiece.

It seems you know something I don't regarding the functionality of inverse.

[Qix-]

Inverse is its own code, [7m. It's archaic and IMO shouldn't exist anymore, but it does. It tells the emulator to reverse the fore- and background colors under the hood. We're not doing anything special there, and so in certain cases where the foreground bright codes (9x) are supported but the background codes aren't (10x), sometimes inverse works.

It's pretty cross platform compatible in that all terminals on non-windows support it and it has first class support in LibUV (I know because I wrote that support myself 🙂) which means it is supported on windows terminals that respond to the *Console() win32 API calls (which should be all of them).

[adalinesimonian]

I haven't had a chance to have a crack at testing this on my Fedora installation or on my MacBook, but if I get you correctly, you're saying using this archaic code fooled Windows into doing the right thing, but on *nix OSes I would have been most likely getting the correct colour output with just bgYellow.black.bold?

[Qix-]

Correct.