Emitting colors to terminals is trivial, but ncurses - the dominant text UI library (since the 1980s!) - needs to hold the color information for the "windows" or frames that it maintains for you so that it knows how to repaint things when you switch from one view to the next (eg, if some kind of popup opens and then gets closed, ncurses maintains state about what was underneath so it can redraw it for you. This was novel in the 80s because of the number of competing terminals; see /etc/termcap for a very good idea of why everyone was happy to let a library do this for you).
* The following is my understanding of the situation; I welcome corrections *
Unfortunately, ncurses encodes the foreground and background as an unsigned int, which only stores 0-255. That bit I said before about ncurses existing since the 80s - unfortunately that's more important than I wish it was; ncurses ("new curses") is merely the OSS variant you find on Linux, it has existed on UNIX (as the "curses" library) in many forms. For Reasons™, the commercial curses implementations of the day all tried to stay binary-compatible with each other. Of course, ncurses did the same.
And so, ncurses is pretty much based on a de-facto ad-hoc standard (AFAIK) that's not really ratified anywhere (it might be, not sure) and which specifies very strict in-memory data structures because of the way the API was originally built. Changing any of this would break binary compatibility.
IIRC, ncurses' author/maintainer, Thomas E. Dickey, hasn't really made any noises about for example adding a new function and doing some kind of backward-compatibility dance to allow ncurses to preserve but ignore the legacy color data. I'm not sure if this would actually be technically impossible or whether it's a case of "eeeeh, that doesn't sound like fun, I don't feel like doing that". I can understand the latter, but I definitely hope the former is not true, as it would be the death knell for truecolor for at least the next 10 years - ncurses isn't going anywhere anytime soon, and it would be the canonical way to get the capability popularized.
In case you were curious to see how much depends on ncurses on your system (uses ldd and assumes "libncurses"; unsure if Linux specific):
(IFS=:; for x in $PATH; do ldd $x/* 2>/dev/null; done) |\
awk '/^\//{FS=":";p=$1;}/^[ \t].*libncurses/{print p;}'
There are some obvious things in here like htop/top, alsamixer, dialog, vim, irssi, links, mc, etc; I assume most of what I'm seeeing is depending on ncurses as a result of pulling in another library.
Your package manager's "list packages that depend on this package" may produce faster results.
Hi i336_, I believe the problem lies not in the fact that there are only 256 values available in an "unsigned int" (an int is at least 16 bits wide). The point is that ncurses requires to work with color pairs, which encode both the foreground and the background color in an index. This was made in order to preserve compatibility with some old HP terminals that were not able to set the two colors separately (using "setaf" and "setbf", like Tektronix terminals used to do).
The problem with direct color is, if you have N colors, the number of pairs is N^2. When N=2^24, indexing pairs would require a variable of size 48 bits at last, but the current ncurses' ABI doesn't allow this.
I believe that almost every modern terminal doesn't use paired colors anymore, but ncurses has always tried to provide compatibility with a wide set of terminals, and I understand their lack of enthusiasm in supporting this.
This sounds like an opportunity for somebody write a backwards-compatible ncurses replacement in a modern systems language. I promise to try using whichever language manages to do this first.
Or even in C! The (n)curses API is ancient -- it dates back to the early 1980s, and has not changed much since then. We've learned a lot about API design over the last 30+ years; we could do much better today.
Fair point, and today's C is far from what it was in the '80s! Regardless, this is an excellent project for a programming language shootout --- ncurses is well overdue for a rewrite, and I'd love to see the C++17 partisans take on the Rust fans, the Go-ers, and the C diehards.
Emitting colors to terminals is trivial, but ncurses - the dominant text UI library (since the 1980s!) - needs to hold the color information for the "windows" or frames that it maintains for you so that it knows how to repaint things when you switch from one view to the next (eg, if some kind of popup opens and then gets closed, ncurses maintains state about what was underneath so it can redraw it for you. This was novel in the 80s because of the number of competing terminals; see /etc/termcap for a very good idea of why everyone was happy to let a library do this for you).
* The following is my understanding of the situation; I welcome corrections *
Unfortunately, ncurses encodes the foreground and background as an unsigned int, which only stores 0-255. That bit I said before about ncurses existing since the 80s - unfortunately that's more important than I wish it was; ncurses ("new curses") is merely the OSS variant you find on Linux, it has existed on UNIX (as the "curses" library) in many forms. For Reasons™, the commercial curses implementations of the day all tried to stay binary-compatible with each other. Of course, ncurses did the same.
And so, ncurses is pretty much based on a de-facto ad-hoc standard (AFAIK) that's not really ratified anywhere (it might be, not sure) and which specifies very strict in-memory data structures because of the way the API was originally built. Changing any of this would break binary compatibility.
IIRC, ncurses' author/maintainer, Thomas E. Dickey, hasn't really made any noises about for example adding a new function and doing some kind of backward-compatibility dance to allow ncurses to preserve but ignore the legacy color data. I'm not sure if this would actually be technically impossible or whether it's a case of "eeeeh, that doesn't sound like fun, I don't feel like doing that". I can understand the latter, but I definitely hope the former is not true, as it would be the death knell for truecolor for at least the next 10 years - ncurses isn't going anywhere anytime soon, and it would be the canonical way to get the capability popularized.
In case you were curious to see how much depends on ncurses on your system (uses ldd and assumes "libncurses"; unsure if Linux specific):
There are some obvious things in here like htop/top, alsamixer, dialog, vim, irssi, links, mc, etc; I assume most of what I'm seeeing is depending on ncurses as a result of pulling in another library.Your package manager's "list packages that depend on this package" may produce faster results.