[JdeBP]

As I noted at https://news.ycombinator.com/item?id=22002036 . (-:

It has been really 16 colours since the days of AIXTerm, even though that did not get formally standardized. Only a couple of places nowadays make the error of conflating bold and bright. It's not really "8 base colours plus highlight" at all, and that's certainly not the case with the tool at hand.

You are also approaching being a decade late with a plea not to use direct RGB colour. https://gist.github.com/XVilka/8346728 started in 2014, for example.

What the tool at hand really tells us is that there are already at least 18 different ways of specifying a colour palette. Perhaps the better idea nowadays is to promote a common 16-colour-to-RGB palette mechanism for TUI applications, akin to mailcap or something.

[hnlmorg]

Direct RGB does still have its place, for example rendering ASCII or block art. Just not for stuff that's intended to be read.

[a1369209993]

We have a common 16-color-to-RGB mechanism: write \e[34m or similar and let the terminal do its damn job.

[JdeBP]

No, you do not have that. For starters, it's still a matter of debate whether the world is wholly ECMA-48:1976 yet. There are people who contend that we cannot assume universal adherence to a 1976 standard.

* https://unix.stackexchange.com/q/548158/5132

* https://unix.stackexchange.com/a/5802/5132

Then there's the matter that only colours 0 to 7 are in fact standardized in ECMA-48. That's 8 colours, not 16. The AIXTerm mechanism has never been standardized, and what has been standardized in the likes of ITU T.416 is both not the AIXTerm mechanism and badly implemented to the extent that people are still today pushing for two long-standing mistakes to be corrected by software authors.

Moreover, not every terminal agrees on how to interpret even the non-T.416 SGR control sequences. Famous and still widely used terminal emulators, such as the Linux built-in one for its KVTs, respond to boldface (SGR 1) by changing colour; in contrast to many terminal emulators where boldface means boldface and isn't a colour change. The control sequences are not the same and cannot be hardwired.

* https://unix.stackexchange.com/a/608930/5132

Personally, I am of the opinion that one can nowadays assume ECMA-48:1976 at minimum as long as one allows for "dumb" as well. But that doesn't mean further assuming the AIXTerm 16-colour mechanism. Until you go and change the Linux KVT's (and others') handling of boldface, and then the "linux-16color" entries in termcap and terminfo, to actually match your claim, your claim will remain incorrect.

(Also note the caveats at https://news.ycombinator.com/item?id=23752827 .)

Then there's the fact that a decent common TUI palette system wouldn't be 16-colour-to-RGB, because that would still need a second map. It would be better than that. That's just a barebones concept. It would be display-element-to-RGB, learning from the design of GUI palettes back in the 1980s, where the colour schemes specified colours for abstract UI elements such as "window title", "pressed button", "file", "directory", "text label", and the like. And indeed from the design of Borland TurboVision, which did the same.