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

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

[Thayne]

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.

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?

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

[Roman Perepelitsa]

On Tue, Apr 7, 2020 at 1:53 AM Thayne <astrothayne@gmail.com> wrote:
>
> https://lists.gnu.org/archive/html/bug-ncurses/2019-03/msg00009.html

Wow, didn't know about this. This behavior is quite surprising to me.

    TERM=xterm-direct print -P '%F{226}this is blue%f'
    TERM=xterm-256color print -P '%F{226}this is yellow%f'

I cannot say whether it's intended but I suspect that a lot of code
that uses color codes above 7 won't work correctly with
TERM=xterm-direct.

Roman.

P.S.

Lean style in powerlevel10k has 8-color option. With a decent terminal
color scheme it looks alright.

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

[Oliver Kiddle]

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