Re: Using 8bit colors in prompt expansion on a terminal with 24bit color support

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Thayne wrote:
> I recently tried out powerlevel10k, but ran into something weird. The
> classic theme had blue backgrounds, where it was supposed to have gray
> backgrounds. After some investigation I discovered it was because the
> `%K` expansion just passes the value through to the setab terminfo
> format, which in the case of "direct" terminfo entries
> (alacritty-direct in my case, but I think it would be the same with
> xterm-direct) assumes it is an RGB value if it is greater than 8.
> Apparently this is intentional behaviour
> (https://lists.gnu.org/archive/html/bug-ncurses/2019-03/msg00009.html)
> for terminfo.

I'm not familiar with "direct" terminfo entries and haven't found much
by way of useful documentation. Does selecting this provide any
particular benefit? Or was it a default setting with alacritty?

Based on a bit of probing, it appears to be meant for explicitly
true-colour terminals with the 256-colour palette being dropped.
$terminfo[colors] reports 32767 which is rather less than a full 24-bit
range but there may be other reasons behind that value. With %F,
%K etc, zsh ends up only filling in the blue part of a sequence that
has separate red, green, blue components. So it would seem there is
no numbered palette. Many prompt themes and other terminal programmes
assume the use of the common 256-colour palette so it is no surprise
that they should break.

> Is it expected that zsh's prompt expansion for colors behaves this
> way?If so, maybe the documentation on it should be more clear that it
> is the users responsibility to make sure that you use 24bit colors
> (with hex) rather than 8bit colors if the terminal expects it (by
> checking for the RGB property in terminfo). Or should zsh map the 8bit
> color to the corresponding 24bit color?

It has always been the case that colours specified with %F, %K etc were
passed through fairly directly and it was left to the user to adapt
according to how many colours their terminal supports. So when moving
between 88 and 256 colour terminals, the same values can have quite
different effects. As far as zsh is concerned, the old values were not
8bit values but terminal-specific values.

That aside, and given how 256-colours is far more entrenched than 65 or
88 ever were, mapping colours may be the best approach. That assumes we
can detect the situation reliably. Is this RGB property documented?
I'm not sure how simple it is to check given that zsh seems to mostly
use termcap sequences.

Oliver