RFC: Allow forcing colorized output #447
Conversation
mislav
left a comment
There was a problem hiding this comment.
For a first contribution to a golang project, this looks great! I like the fact that a palette is now passed around as an instance— this would allow us to, for example, pass a modified pallete in the future based on the person's color configuration.
This does require a substantial change to the code, though, which makes me reluctant to approve as-is, but I have no specific code feedback to give you right now. We would need to think about the issue some more and think about what the best solution might be; but I imagine that it could be in the direction that you are proposing.
BTW, what do you think about supporting git-style color flags?
--color,--color=always--color=never--color=auto--no-color
Co-Authored-By: Mislav Marohnić <[email protected]>
I think that's great, it will just feel natural to git cli users 👍 |
|
@mislav I'm closing this in the meantime since we don't want this as is. I'll likely reopen/update with CLI interface you proposed so we get an idea of how it could look like. |
|
I started on a PR tonight to allow saving a custom style for the Glamour renderer to the config file. It’s a smaller scope than what this PR was trying to tackle. Is that something that’d be welcomed or would a larger design discussion need to happen before pressing onward? |
|
@jessemillar That sounds interesting; I'd love to see a PR! Was the goal for your change to try solve rendering on lighter backgrounds? If so, have you tried if "auto" style works? Right now we hardcode it to "dark", but maybe "auto" would correctly detect the background color of one's terminal. |
|
@mislav I’m just real particular about having a standard color scheme across my terminal so I wrote a custom Glamour theme matching the Nord color palette that I’d like to use with |
|
@jessemillar Sure, shoot us a PR! I can't promise that it will be merged soon, since every new feature needs to pass a design phase (i.e. we have to think about naming, how it fits into our roadmap, future-proofing), but I think some kind of color-configurability might be on our radar soon. |
…li#447) Co-authored-by: jer <[email protected]>
This is about being able to force colorized output in environments that are not detected as terminals.
My usecase is to run this for example in
watchwhich supports colored input with-cflag.eg:
watch -c -n60 gh pr status.This adds a
--force-colorglobal flag to override auto detection.This is my first contribution to an open source golang project. Comments welcome!
Let me know if you guys are open to such a feature.
Looking at #364 it seems it would probably be better option to accept a "color" enum (always/never/auto) to force enable/disable or detection.
I'll be happy to update this with tests if there is interest.