- for visual impairment reasons (eg high contrast colours)
- or to differentiate different servers (eg different background colours for dev or prod servers)
- or have less contrasting colours to reduce eye strain (eg the Solarized colour schemes)
- might suffer from colour blindness so pick colours that contrast better with their condition
- or even just those that prefer a white or other non-black backgrounds for readability reasons (eg they might be dyslexic and find a non-black background or different shades of text easier to read).
I do fall into two of those categories and run into this issue a lot since there is a trend these days for developers to hard code colour values into their applications.
Equally, some developers use the "you can select a custom colour map - I just define a pretty default" argument and while that's slightly better, the best option would be still to default to the standard 8 colours (or the default unformatted text) and let users opt into RGB values if they wish. This will save your users from constantly having to define the same colour palettes in every application.
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.
* 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.
In particular, it allows your users to completely disable the highlights by using TERM=dumb.
Also, please check if the output is a tty (the isatty libc call) I don't know how many applications with fancy coloured output that looks completely broken when redirecting to a file.
That's my point :)
Those are actually called "RGBI"[0] colors (which would make the 8 base colours "RGB", though I haven't seen that usage), although that's clearly not what you mean by "RGB values".
0: 1 bit each for red,green,blue,intensity: #(r·AA+i·55,g·AA+i·55,b·AA+i·55)
Wikipedia has good introduction to the different SGR colour parameters: https://en.wikipedia.org/wiki/ANSI_escape_code#Colors
I'm talking about 3/4-bit (8/16 colours) not 8-bit (256 colours) nor 24-bit ("true colour"). The 3/4-bit colour palette is configurable in most terminals. True colour is not.
Can you clarify what your suggestion is please? I assume you're talking about ANSI color escape sequences. There are 3 different ways colors are represented using ANSI color escape sequences (see https://en.wikipedia.org/wiki/ANSI_escape_code#Colors)
1. Using the 16-color palette which is dynamic and under user control.
2. Using the 256-color palette, which are hardcoded colors.
3. Specifying 24-bit colors (RGB), which also hard-coded colors.
Are you asking developers of terminal applications to use neither (2) nor (3)? If so, that seems like an extraordinary, and inappropriate, request. I do hope however that developers of terminal applications make it possible to configure the application to use (1).
For example, do you disapprove of the existence of all syntax highlighting color themes unless they use only the base 16 colors?
* https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47...
* http://jdebp.uk./Softwares/nosh/guide/commands/TerminalCapab...
The issue is that these "stateful" URLs don't work when accessed directly. Try this one that I got by fiddling with the colors a bit:
https://terminal.sexy/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2Hc...
The site hangs and does not initialize.
Cheers
(I just emailed the site's author about it being discussed here as well)
https://elixir.bootlin.com/linux/latest/source/Documentation...
That would be very useful :)
Or this:
His script isn't truly random, but it does contain maybe twenty themes or so. During a normal day, he's working in 10+ terminals on various servers. The colours and placement of the terminals helps him to remember which server he's working on. So colours are only there to provide visual glue to help him determine the environment he's on, rather than being a personal preference for some theme. It doesn't matter that the grass theme is ugly, it's just the green terminal window which is currently an ssh session the stage database server.
Thanks for the submission.
