Adding RGB ANSI colours for compatibility with Linux terminal emulators

[Souravgoswami]

Submitting questions

The Current colorize implementation goes like this: https://github.com/crystal-lang/crystal/blob/c2c2276ec667171af5c2347490f49acdbdc4a3ca/src/colorize.cr#L104

Problem: Terminals with different specified colour can make the red blue or whatnot...

But the "\e[38;2;r;g;bm" sequence works fine with any RGB decimal values. Although this can break in TTYs. So we may detect if it's a TTY or not:

• On terminal emulators

  ENV.has_key?("COLORTERM")     # => true

• On TTYs

  ENV.has_key?("COLORTERM")    # => false

  Additionally we can pass any RGB colour or hex colour to the terminal in the similar way. It has to convert RGB to hex though. But again, won't work on TTYs. It's not tested on windows either... Works fine on Unix (FreeBSD, DragonflyBSD, GhostBSD), and GNU/Linux and Android Termux.

[nanobowers]

I think this is expected behavior for ANSI 16-color mode: https://en.wikipedia.org/wiki/ANSI_escape_code#Colors Only the concept of the colors is standardized, as you can see in the wiki-entry different terminals and tools render the colors to a different RGB value. Also as you mention, in some terminals one could redefine "blue" to 0xFF0000 (red).

Some older terminals dont support 24b color mode or even 256 color mode, so i think the Colorize approach is to force the developer to decide which color scheme to use ColorANSI, Color256 or ColorRGB. Based on other libs i've seen in py/rb/js I detection is a shaky heuristic that is not something theyd want to put in Standard library, IMO.

On a side note, I was working on something that used x11 colors (e.g. "limegreen") and ended up mapping these into Colorize::ColorRGB values via a String parameter, but quickly found that the definition of "red" in the x11 color potentially conflicts with :red used by Colorize::ColorANSI. oops.

In any event, would be nice to have an interface that

• takes String values for the colors
• allows the coder to specify a preferred method of handling color output, but accepts a general color of more generally defining color (either by ansi-name, x11 name or rgb value) Perhaps there's already a shard to do this?