Allow to configure colors using an environment variable

[weiznich]

This commit add support for configuring colors used by cargo through a
environment variable (CARGO_COLORS). The used syntax for the environment
variable is similar to that one used by gcc (GCC_COLORS).

Example: CARGO_COLORS="status=01;2:warn=01;3:error=01;1:default:01;231:blocked=01;4"

The current state should be seen as a proof of concept and demo to see if this functionality is wanted. I've only tested the code on linux so far.
For a final implementation the interpretation of the escape codes may be improved.

Resubmit of #3873

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

cc @rust-lang/dev-tools, this has an impact on not just Cargo but also tools like rustc/rustup, and I'd be curious to hear others' thoughts as well.

[nrc]

Thoughts:

• I wonder whether we should unify colouring across all the tools?
• Could we use a config file rather than an env var? This seems like a lot of info to stick in an env var.
• I'm vaguely in favour of letting users customise their experience like this, but worry a bit about the cumulative complexity of lots of small features

[weiznich]

I wonder whether we should unify colouring across all the tools?

I haven't looked in the implementation of the other tools yet, but this seems to be a good idea. Maybe we should factor out the code in a separate crate and use it everywhere? In this case the name of the environment variable should maybe be changed to RUST_COLORS?

Could we use a config file rather than an env var? This seems like a lot of info to stick in an env var.

In theorie we could use a config file for this, but this would prevent the main application of this. It is not that uncommon to work with several terminal emulators in parallel (say the build in terminal in vscode or emacs and the system terminal emulator). Now those could use different color schemes. So they must use a different configuration for the color codes. This would be quite hard to achieve with an config file.

See this comment on the old pull request for more details.

[ayosec]

@nrc

I'm vaguely in favour of letting users customise their experience like this, [...]

A common issue with Rust tools is that they use bright colors on the default background. I have the background set to white, and redshift (similar to f.lux on MacOS) makes the contrast between bright colors and white background even smaller during the night.

It is annoying (but still doable) to change the profile of the current tab in my terminal every time I start using cargo/rustc.

[bors]

☔ The latest upstream changes (presumably #4162) made this pull request unmergeable. Please resolve the merge conflicts.

[weiznich]

@alexcrichton f8fb0a0 broke the current implementation. It seems not possible to use custom color codes through termcolor, so this will not work anymore.
There is this open pull request that adds support for more color types.

I think the best way forward is to get this pull request merged. After that one could write a small utility crate that could do the parsing of the color codes from an environment variable. This crate could then be used to implement the color feature in cargo, rustc, …

[alexcrichton]

Sounds reasonable to me!

[alexcrichton]

Closing due to inactivity, but please feel free to resubmit with a rebase!

[dwijnand]

@weiznich the changes in BurntSushi/ripgrep#452 were effectively merged with BurntSushi/ripgrep#766, do you feel like rebasing this branch now to ship the change?

[weiznich]

@dwijnand Rebasing that branch would be great, but it seems like I currently missing the time doing this. Feel free to grab this if you have time.