8-bit/24-bit color support about chalk HOT 12 CLOSED

Interesting, thank you for the suggestion. I'll have a look at this 😄

from chalk.

So after some testing, it seems that KDE's konsole is the only terminal currently supporting 24-bit this. Worse, other terminals interpret these codes incorrectly, making the output unpredictable.

I'll still have a look at 8-bit though, all though as you said that doesn't seem to be widely supported either.

from chalk.

Seems like 8 bit color codes are indeed better supported! I've created the ansi-8-bit package wrapping these codes, and will think about a good way to wrap these in chalk.

@sindresorhus any ideas what the best api would be? The ansi-8-bit module works fairly similar to ansi-styles, so I'm thinking of simply adding a Chalk.rgb(int, int int) doing the same as the other chalk functions.

from chalk.

Actually, that API wouldn't work - as there's both a foreground and a background rgb styling function.

How about simply exporting the functions

chalk.foreground = function (r, g, b, str) { return ansi8bit.fg.getRgb(r,g,b) + str + ansi8bit.reset; };
chalk.background = function (r, g, b, str) { return ansi8bit.bg.getRgb(r,g,b) + str + ansi8bit.reset; };

from chalk.

What is the terminal support for 8-bit colors? I'm resistant to add something that most won't use because of lack of widespread support. I've considered it multiple times in the past, but have never come up with a situation where I would personally use it. What's the use-case?

from chalk.

Support is pretty widespread, any terminal with xterm support - which is any terminal I've ever used on OS X (terminal.app and iTerm) and linux. On windows I wouldn't know ;-)

The use case is not that common I suppose. On the other hand, there are clearly people asking for it, the effect is pretty nice, and the overhead is almost zero:

du -hs node_modules/ansi-8-bit/
  12K

from chalk.

Ya, I'm just hesitant of adding things most people wouldn't use as that would probably be better fit as a separate package. Might be better to just recommend a module of yours in the readme instead. As I would most likely recommend against using it in the readme for reusable things anyways.

Let me mull it over :)

from chalk.

Fair enough 👍 let me know :)

from chalk.

I've thought this over for a while and I still don't think it makes sense to add this to Chalk. I want to keep Chalk focused on reusable modules and targeting the 90% use-case. Every new method adds overhead for users. More things to learn and having to care about. Some users might want more colors, but for reusable modules it doesn't really make much sense.

Can you instead add a section called 256-colors or something to the bottom of the readme linking to your module and saying when it makes sense to use and when not (reusable modules)?

from chalk.

@jbnicolai ⬆️

from chalk.

Woops, completely lost sight of this one. Will do it later today 😄

from chalk.

#73 had some further work on this topic.

from chalk.