Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Better 256 color detection #29

Closed
rschristian opened this issue Apr 22, 2023 · 0 comments · Fixed by #30
Closed

Feature Request: Better 256 color detection #29

rschristian opened this issue Apr 22, 2023 · 0 comments · Fixed by #30

Comments

@rschristian
Copy link

rschristian commented Apr 22, 2023

The determination method for 256 color support is unfortunately quite conservative, as many terminals support it without having a name ending in -256color:

kolorist/src/index.ts

Lines 51 to 53 in a81083d

TERM && TERM.endsWith('-256color')
? SupportLevel.ansi256
: SupportLevel.ansi;

For example, I use alacritty:

$ infocmp alacritty | grep colors
        colors#0x100

Alacritty does support True Color, but terminfo/ncurses is a bit silly and doesn't allow for multiple color specs in the same file. One would need need to look at alacritty-direct to get that info, but I digress.

I'm wondering if there's a non-awful way to get better detection here? I might take a look at other libraries and see what they're doing; my terminal is missing some much-needed color variety.


Edit: Well quick rabbit hole seems to indicate if you want to actually detect 256 support, you're out of luck; there's no reliable cross-platform method. However, $COLORTERM=truecolor seems somewhat viable as it's fairly popular across tools, and support for truecolor I believe grantees support for 256. Even Windows Terminal might support it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant