I've read and reread the content on those links several times now and am trying to reconcile with what I see happening with color_content() in my own program. Let me see if I've got this straight:
1. When start_color() is called it initializes the ncurses color table with the first "standard' SGR colors (1 - 8, COLOR_BLACK - COLOR_WHITE).
2. When start_color() is called it does not attempt to enumerate any other colors in the table and does not attempt in any way, shape, or form, to match the underlying terminal palette.
3. The terminfo *may* describe RGB encoding in the "initc" extended term attribute and nurses will based RGB distribution on that.
4. Assuming the underlying terminal can support it, init_color() will define a custom color in the ncurses color table and make the corresponding change to the underlying terminal.
5. When color_content() is called, there is no guarantee that it will be accurate.
If I have overlooked any key points please let me know. It seems like the punchline is that if I want a guaranteed behavior from color_content() the I will have to initialize my own palette. Is that a fair statement?
On Wed, Feb 05, 2020 at 12:05:43PM -0600, Bryan Christ wrote:
> In order to find an unused color in the ncurses palette, I run a simple
> loop test looking for a free color. The code is basically something like
> color_num = COLOR_WHITE + 1; // skip built-in colors
> color_content(color_num, &r, &g, &b);
> if((r + g + b) == 0) break;
> Now the odd thing is that this works except when the value of "color_num"
> is a multiple of 8. When "color_num" is a multiple of 8, it incorrectly
if the special capability RGB is set, ncurses can make useful assumptions
about the color content. If it's not set, ncurses can only assume ANSI
color palette (8 colors).
RGB is documented in user_caps:
For the latter,
that's in the curs_color manual page,
in the discussion of start_color:
Thomas E. Dickey <address@hidden>