Re: Strange behavior with color_content()

[Tim Allen]

On Fri, Feb 07, 2020 at 01:15:09PM -0600, Bryan Christ wrote:
> 5.  When color_content() is called, there is no guarantee that it will be
> accurate.

It will be accurate if you're asking for the content of a color
previously defined with init_color(), or if you happen to be using a
direct-color terminal variant like xterm-direct (in practice, I think
nobody uses direct-color variants yet).

There are escape codes to query a terminal for its current palette, but
they're not described by terminfo (so far as I can tell), and I don't
know how widely supported they are in actual terminals. I think they're
also pretty slow, too.

> 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?

There are somewhat-common terminals that do not support custom palettes,
so init_color() can't be used. For example, the QTerminal widget (that
powers KDE's Konsole emulator), and tmux (unless tmux's outer terminal
advertises the non-standard `Tc` terminfo capability).

In practice, every terminal that supports more than 16 colors defaults
to the xterm 256-color palette. I think most applications ignore
color_content() and maintain their own color cache with different
defaults.

I wonder if ncurses should add another custom terminfo string for
"default palette", so color_content() can be more reliable.