Open willghatch opened 9 years ago
Good suggestion, and thanks for linking to extra info regarding support.
When working in true color mode I think we should accept hex strings and instances of color% as well as the normal (existing) symbols. Allowing color%, lets users specify the RGB values or a human readable string such as "SkyBlue".
Also, I think it should be opt in via something like (use-true-color-commands), which enables the use of hex strings and color%. Without the call, it will be an error to use them.
This way users know what they ask for might not be what they get, as it does not work on Windows, or several terminals on nix. Long term/Enterprise Linux distros would most probably not support it for a while yet either, mine currently doesn't (SUSE).
This way by using the default mode of require and forget, everything will work the same regardless of platform, but for users who are willing to take the risk and know the environment they can still enable it.
I think this should be in a version after v1.0 because I want things to stabilise first and make v1.0 a great release with a solid base.
Sounds great. I'm also quite new to racket, so I don't know about established color objects, but I definitely agree they should be supported. I'm just happy that it will get in - I'm a big fan of terminal true color support.
On January 31, 2015 1:18:26 PM MST, hopkinsr notifications@github.com wrote:
Good suggestion, and thanks for linking to extra info regarding support.
When working in true color mode I think we should accept hex strings and instances of color% as well as the normal (existing) symbols. Allowing color%, lets users specify the RGB values or a human readable string such as "SkyBlue".
Also, I think it should be opt in via something like (use-true-color-commands), which enables the use of hex strings and color%. Without the call, it will be an error to use them.
This way users know what they ask for might not be what they get, as it does not work on Windows, or several terminals on nix. Long term/Enterprise Linux distros would most probably not support it for a while yet either, mine currently doesn't (SUSE).
This way by using the default mode of require and forget, everything will work the same regardless of platform, but for users who are willing to take the risk and know the environment they can still enable it.
I think this should be in a version after v1.0 because I want things to stabilise first and make v1.0 a great release with a solid base.
Reply to this email directly or view it on GitHub: https://github.com/hopkinsr/terminal-color/issues/2#issuecomment-72334442
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I like this library. One thing I would add as a feature request is a syntax for 24-bit "true color" support. In recent years they've made a standard for specifying 24-bit color for terminals and most terminal emulators support it. Here is an old gist that explains what ones support it so far:
https://gist.github.com/XVilka/8346728
You could have the interface be something like this (maybe accepting the strings with or without the leading # sign):
(displayln-color "Purple on orange" #:fg "#9C0874" #:bg "#F09C26")
The sequences to get 24-bit color are:
\e[38;2;R;G;Bm
Where R, G, and B range from 0 to 255. Replace 38 with 48 for background.
This is pretty well supported currently for Unix terminal emulators (including OSX), and I expect it to gradually take off as the norm for most console applications that want to deal with more than 8 colors. Windows may never support such a thing, but I think it's worth having for those who program for Unix.