Hello,
I want to use terminal.nim true colors caps, but it says i don't have a true color terminal.
I've looked the terminal.nim source, and all i understand is it test the «trueColorIsSupported» field from a PTerminal object.
I don't know how this field is filled, i've seen only an opening of a new term, but no filling.
Anyway, i'm using a true color terminal (alacritty).
Here is the code block for my test.
if isTrueColorSupported() == true:
enableTrueColors()
else:
echo "this need a true color terminal"
Thank you.
thank you for the answers.
Indeed, before testing if the true color mode can be supported, we must enable it. First point. The second is , by reading the source of enableTrueColors , we have this when target is not MS-Windows™ :
term.trueColorIsSupported = string(getEnv("COLORTERM")).toLowerAscii() in [
"truecolor", "24bit"]
term.trueColorIsEnabled = term.trueColorIsSupported
so COLORTERM must be exported in the shell environment with _truecolor or _24bit value. That was not the case for me (not defined). I've exported it with _truecolor and it was ok with this one:
enableTrueColors()
if isTrueColorSupported() == true:
echo "victory!"
else:
echo "this need a true color terminal"
I've asked to several people if COLORTERM was set in their env.
Answers vary …
For Kitty, that's ok (set to truecolor). For rxvt-xpm, it's set to rxvt-xpm.
It seems that testing COLORTERM is the best way to know if a term has true colors caps (s-lang does this way and ncurses … does not know what color beyond 16 is :) ).
If COLORTERM can contain "YES!" , for sure it will be hard to test.
I see two workarounds:
or
I've found the two options quite lame, but YMMV.
The rxvt family and maybe more use it for another purpose (they do not support true color). So, it was always "unreliable". It may as well always have been a NIMTRUECOLOR. I agree a way to statically override may make sense (maybe statically override the name of the var as well?).
The best way (at least in the world of esc seq controls) doesn't really exist. I think it would be a special escape sequence to query everything a program might want to know about the terminal - both capabilities and current states. Then the source of information would be authoritative for said information. But the world evolved a different way from this. So, this is not a viable road to terminal portability.
It also bears mention that most sets of users disagree enough on color schemes/themes (night mode, etc.) or even color at all that a per-user config file override may also make sense. I happen to have a setup with both white background and black background terminal emulators and I key configs based upon an LC_THEME environment variable (transparently propagated by sshd until recently). (See lc for examples), and cligen/humanUt also supports using true colors in the xterm/st/alacritty/kitty family of true color esc seqs. So, that set up may also be useful to you. (The whole esc seq generation system is under 60 lines of Nim and you might also just do your own...)