iris

iris copied to clipboard

Currently, Iris checks stdout and stderr 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:

• Disable colouring if the NO_COLOR / NO_COLOUR environment variable is set
• Disable colouring if the <MY_APP_NAME>_NO_COLOR / <MY_APP_NAME>_NO_COLOUR environment variable is set
• Disable colouring if the TERM environment variable is set to dumb
• Disable colouring if one of --no-color / --no-colour / --disable-color / --disable-colour options is provided
  • Iris should display only --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 via internal) with the following values:

• auto (default): detects colouring automatically by checking handles, environment variables and disabling CLI options
• never: disables colouring

  Colour disabling options should behave exactly as --colour=never

• always: always prints colours; has higher priority than any other option

Implementation

• [ ] Add a config option for my application name
• [ ] Add new module Iris.Cli.Colour
  • [ ] Enum type for always / auto / never options
  • [ ] CLI parsers for above-mentioned colours
  • [ ] Add this option by default to env
• [ ] Add a new module Iris.Colour.Detect with the implementation of the colouring detection logic described in the beginning of this issue
• [ ] There should be no separate option for stdout and stderr. In other words, env variables and CLI disable / enable options apply to both stdout and stderr. The only different part is whether the specific handle supports colouring or not

I'll have a go

@chshersh I'm a bit confused by strings:

• Iris.Colour.Formatting uses Bytestring
• Iris.Tool uses Text

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.