Closed chshersh closed 1 year ago
I'll have a go
@chshersh I'm a bit confused by strings:
As I understand the former is about output and the latter about command line parsing, so they will probably coexist smoothly, but still feels a bit odd
Is this deliberate?
Since text-2.0
, Text
is now a UTF-8 array of bytes. I'd love to move the entire API towards Text
for consistency so yes, the existing situation around having both ByteString
and Text
is a bit unfortunately 😞
If you feel like it, you can create a separate issue to change types in Iris.Colour.Formatting
from ByteString
to Text
and work on it separately. It'll be a breaking change but that's okay at this stage.
Currently, Iris checks
stdout
andstderr
handles to decide whether they support colouring or not. And that's all. This issue is about improving the detection of colouring via CLI options.Description
Following CLI Guidelines, the new logic for detecting colouring should be as follows:
NO_COLOR
/NO_COLOUR
environment variable is set<MY_APP_NAME>_NO_COLOR
/<MY_APP_NAME>_NO_COLOUR
environment variable is setTERM
environment variable is set todumb
--no-color
/--no-colour
/--disable-color
/--disable-colour
options is provided--no-color
with the description. Other options shouldn't be displayed. Use internal for other options.Additionally, Iris should provide the
--color
option (with the--colour
option as well being hidden viainternal
) with the following values:auto
(default): detects colouring automatically by checking handles, environment variables and disabling CLI optionsnever
: disables colouringalways
: always prints colours; has higher priority than any other optionImplementation
Iris.Cli.Colour
always
/auto
/never
optionsIris.Colour.Detect
with the implementation of the colouring detection logic described in the beginning of this issuestdout
andstderr
. In other words, env variables and CLI disable / enable options apply to bothstdout
andstderr
. The only different part is whether the specific handle supports colouring or not