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
Allow non-ansii colors #855
Labels
new feature
New feature or request
Comments
Thanks for opening your first issue here! In case you're facing a bug, please update navi to the latest version first. Maybe the bug is already solved! :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Hey, thank you for working on the project!
I recently learned about this project and wished I had known it sooner.
I already forgot waaay too many CLI arguments/tricks that would've fit perfectly into a
cheat
file 🤦Anyhow, as a terminal fan, I would appreciate it if it would be possible to allow more than a few colors so that I can fully customize the look and feel.
Describe the solution you'd like
I would like to be able to provide RGB colors in the
config.yaml
file instead of the pre-defined ANSI color names.I understand that this might confuse novice users who may use an unsupported terminal or color setup.
Maybe the feature doesn't need to be prominently advertised or simply linked to the crossterm documentation?
To minimize the necessary changes, I think, it should be possible to split the yaml "color string" by the
,
symbol and then check how many groups exist. If 1 => normal behavior, if 3 => convert it to u8 tuple, otherwise fail.For the tuple case, the
From<(u8, u8, u8)>
function could be used.https://github.com/crossterm-rs/crossterm/blob/08762b3ef4519e7f834453bf91e3fe36f4c63fe7/src/style/types/color.rs#L197-L217
I have 0 experience with
crossterm
and little rust programming experience, but just looking at the source code, it seems like it should return the same type and not require any other changes. But I have no idea if this actually works as I think it would.A 'nicer' solution would probably be to allow users to specify this not only as a string but as a tuple of ints. Then the yaml/code mapping is clearer.
Describe alternatives you've considered
None
Additional context
The text was updated successfully, but these errors were encountered: