colors not displayed with TERM=xterm
I notice that keyb does not use any colors with TERM=xterm, but it does work with TERM=xterm-color.
I usually just use TERM=xterm, can I force keyb to use colors without changing my $TERM?
(Note: This used to work with v0.3, I just upgraded to v0.7 and lost colors)
Hi, thanks for opening an issue. Could you share the following information:
- OS
- Terminal Emulator
- With tmux?
- Environment variables:
- TERM
- COLORTERM
- TERM_PROGRAM
- CI
- CLICOLOR
- NO_COLOR
This is most likely an issue with the underlying color libraries termenv or lipgloss as these were updated since v0.3.
Thanks, I'm using Ubuntu 22.04.4 LTS and XTerm 393, without tmux/screen.
- Environment:
- TERM=xterm
- COLORTERM unset
- TERM_PROGRAM unset
- CI unset
- CLICOLOR unset
- NO_COLOR unset
The other features all seem to work!
Hmm, CLICOLOR_FORCE=1 keyb does work as a workaround, I guess that's okay... although I think most xterm users just use the default XTerm $TERM name, so won't realize there are colors!
I managed to replicate this with xterm and the examples in termenv.
- With default
TERM=xterm xterm, termenv'shello-worldexample returns no colors as the color profile is ASCII. - With
CLICOLOR_FORCE=1 TERM=xterm xterm, there are colors as the color profile switches to ANSI256. - ~~With
TERM=xterm xterm +cm, the color profile is ANSI256 as the+cmflag enables support for ANSI escape sequences.~~ Edit: My bad, this doesn't actually work.
However, you mentioned that colors were working before in v0.3.0. I didn't manage to replicate that - colors were still not working for me with the default TERM=xterm xterm and the rest of the behaviour was exactly the same as above.
For the fix, I could add the following:
if termenv.EnvColorProfile() == termenv.Ascii {
lipgloss.SetColorProfile(termenv.ANSI256)
}
but I don't feel comfortable messing with the user's terminal configuration. Instead, I'll probably just add a note with the workaround above for xterm users or any other users that lack colors.
Edit: Might be a good idea to implement this in the future, but the current workaround seems simple enough.