A suggestion for color handling on modern terminals

[Tim Allen]

According to the terminfo(5) manual page, the two main models for  
color handling in the Days of Yore were "arbitrary combinations of  
available foreground and background colors" ("Tektronix-like"), or "a  
limited number of definable foreground/background pairs". ("HP- 
like"). It's obviously easier to make a Tektronix-like terminal  
follow HP-like behaviour than the other way around, and this (I  
assume) is why the curses API presents HP-like operations which can  
be implemented on either Tektronix-like or HP-like terminals.

However, it also means that the value of "COLOR_PAIRS" in curses, and  
"pairs" in terminfo are lies. At least for the xterm variations I've  
looked at, "pairs" is set to "colors" squared, which is not strictly  
true: after you call use_default_colors(), -1 becomes available as a  
"color", and the theoretical number of pairs you could require is  
(colors + 1) squared.

For xterm-256color, "pairs" is an even bigger lie - although 256  
squared is 65536, "pairs" is capped at 32767 even though curses.h  
seems to define COLOR_PAIRS as an int, which is more than capable of  
storing the number 65536 on modern hardware. (I assume "pairs" is  
capped in the terminfo database for binary backwards-compatibility  
reasons).

For most curses apps this isn't a problem - you can allocate color  
pairs for interface elements like "button", "menu", "text entry",  
etc. and probably never hit the 64-pair limit of xterm, let alone the  
limit of xterm-256color. But some curses applications can't easily  
predict in advance what colors they'll need; anything that tries to  
display character-cell graphics (like libcaca[1]), or for example  
tools like GNU Screen[2] that try to implement terminal emulation on  
a terminal. Since it's impossible to allocate enough color pairs to  
cover every possibility, such programs are forced to re-allocate  
color-pairs on the fly - and hope they'll never be asked to display  
more color pairs than they have at their disposal[3].

My suggestion is this: When ncurses initialises itself, queries  
terminfo and discovers that it's running on a Tektronix-like terminal  
(presumably, one that defines setaf/setab), it should recognise that  
"pairs" in the terminfo database is a lie, and set COLOR_PAIRS to   
(colors+1) squared rather than the contents of "pairs". Perhaps it  
should cap the new value to INT_MAX, just to be on the safe side.

I don't mind having a go at implementing this myself (it seems simple  
enough and might even be fun) but obviously I don't want to go ahead  
if people think it would be a bad idea.

[1]: http://libcaca.zoy.org/
[2]: http://www.gnu.org/software/screen/
[3]: While this might have been crazy-talk in the days of 80x24  
terminals, I personally had a workstation at my last job with two  
1600x1200 monitors in a 2400x1600 configuration. My favourite font  
Terminus' smallest legible size is 6x12 pixels, giving up to  
(2400*1600)/(6*12) ~= 53333 character cells visible at once; more  
than enough to overflow the 32768-color-pair limit.