Unexpected basic 16 terminal colors displayed on some apps

[haxibami]

On other competing terminals (e.g. alacritty, foot), colors mapped to ESC[38;5;⟨n⟩m, n in {0..15} (= 0-15 in 8-bit, 256 colors) are the same as ESC[⟨n⟩m, n in {30..37, 90..97} (= basic 16 colors), but on rio this seems not to be the case. Below is an example.

16colors.sh:

#!/usr/bin/env bash

echo "\$TERM: $TERM"
echo "\$COLORTERM: $COLORTERM"

for i in {30..37} {90..97}; do echo -e "\e[${i}m ESC[${i}m \e[0m"; done

for i in {0..15}; do echo -e "\e[38;5;${i}m ESC[38;5;${i}m \e[0m"; done

This affects some terminal apps, such as bottom and neofetch. These apps (probably) get basic 16 colors (9, 10, 11, ... or LightRed, LightGreen, LightYellow, ...) from 0-15 in 8-bit 256 colors, resulting in different colors being displayed on rio.

[raphamorim]

Hey @haxibami thanks for the issue and sorry for late reply,

I can reproduce it on latest marking as a bug.

just to take note: which OS are you using and which rio version?

[haxibami]

OS: Linux (Arch Linux, official package) Rio Version: 0.0.35

[LuarRaNa]

I am not sure if it is related but using nushell I get the following results compared to Alacritty. The value for "green bold" in Rio is lighter than it is shown in Alacritty. The same for "red bold" and other ansi colors in bold. Even comparing "green" and "green bold" in Rio shows the difference.

OS: macOS Sonoma Rio Version: 0.0.36

[LuarRaNa]

Digging a little deeper, I found that Alacritty and Wezterm have a setting related to bold drawn text using the bright color palette. Alacritty: draw_bold_text_with_bright_colors default false. Wezterm: bold_brightens_ansi_colors default true At first Wezterm behaved similarly to Rio but by changing its option to false, it displays bold text correctly.

[nat-418]

Same issue with Rio 0.0.34 on NixOS 23.11.

[cwegener]

Is this related to the existing issue? https://github.com/raphamorim/rio/issues/188

[raphamorim]

Yea, is connected partially with @cwegener , the thing is that rio (today) sets colors based on RGBA >255, to fix this specific issue is basically correct the default colors. Probably I will patch it for 0.1.0 which will take longer to release, but if anyone would like to pick up the changes and apply for the branch 0.0.x I can make a release with the fix.