You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR adds a new --color CLI option that controls whether the output should be colorized or not.
This is implements part of #16727 except that it doesn't implement the persistent configuration support as initially proposed in the CLI document. I realized, that having this as a persistent configuration is somewhat awkward because we may end up writing tracing logs before we loaded and resolved the settings. Arguably, it's probably fine to color the output up to that point, but it feels like a somewhat broken experience. That's why I decided not to add the persistent configuration option for now.
Test Plan
I tested this change manually by running Red Knot with --color=always, --color=never, and --color=auto (or no argument) and verified that:
The reason will be displayed to describe this comment to others. Learn more.
This sounds a bit like we would actually detect if the terminal emulator supports colors. What's actually happening is just a isatty check (+ checks for NO_COLOR etc). So I tend to write something like
Suggested change
//github.com/ Automatically detect if color support is available on the terminal.
//github.com/ Display colors if the output goes to an interactive terminal.
One more question: Would it make sense to move this option to the top level instead of knot check? It seems like other sub-commands might also make use of that option in the future. uv also has it as a top-level option.
One more question: Would it make sense to move this option to the top level instead of knot check? It seems like other sub-commands might also make use of that option in the future. uv also has it as a top-level option.
Absolutely. There are options that we should move and I'll move them all together
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MichaReiser
requested review from
carljm,
AlexWaygood and
sharkdp
as code owners
Summary
This PR adds a new
--colorCLI option that controls whether the output should be colorized or not.This is implements part of #16727 except that it doesn't implement the persistent configuration support as initially proposed in the CLI document. I realized, that having this as a persistent configuration is somewhat awkward because we may end up writing tracing logs before we loaded and resolved the settings. Arguably, it's probably fine to color the output up to that point, but it feels like a somewhat broken experience. That's why I decided not to add the persistent configuration option for now.
Test Plan
I tested this change manually by running Red Knot with
--color=always,--color=never, and--color=auto(or no argument) and verified that: