Support CLICOLOR and CLICOLOR_FORCE

[Timmmm]

It would be good to support CLICOLOR and CLICOLOR_FORCE as described here. It's the closest thing to a standard for controlling colour output that exists and is fairly popular.

[BurntSushi]

I'm not so sure about it. And it is certainly not the only thing in this space. For example, folks requested NO_COLOR support in #13. I was skeptical personally, but did ultimately relent. Now CLICOLOR and CLICOLOR_FORCE are more expressive than NO_COLOR, so they aren't the same thing exactly, but they are overlapping. And since termcolor already supports NO_COLOR, a decision would need to be made on which one overrides the others.

I am still not sure if supporting NO_COLOR was the right thing or not. But I do not think termcolor should become a dumping ground for every possible way that colors can be enabled/disabled. On top of that, if you want to support something lke CLICOLOR in your own application, it should be relatively straight forward to do.

[Timmmm]

I agree, I hadn't heard of NO_COLOR. Unfortunately it seems like it was an effort started by somebody who hadn't heard of CLICOLOR and now they want to "win". Not a great situation, especially because CLICOLOR is better and came first.

As a user I would be happy to run a configuration function at the start of main() to choose how the colour is enabled/disabled. I just don't want to have to deal with checking environment variables / is_tty myself.

How about this?

fn main() {
 
 termcolor::enable_color(termcolor::Enable::AutoClicolor);
...

You could have options like ForceOn, ForceOff, AudoNoColor, AutoCliColor, AutoAll and so on. Set the default to whatever it does now for backwards compatibility.

[Timmmm]

Though, feel free to close this if you like. I decided to use the coloured crate instead because it supports CLICOLOR and had a slightly simpler API as far as I can tell.

[BurntSushi]

I decided to use the coloured crate instead because it supports CLICOLOR and had a slightly simpler API as far as I can tell.

Yes, because it isn't as portable as this crate. termcolor's API is more complex out of necessity: it supports the Windows console APIs.

I have always advocated that if you don't need to support the Windows console APIs, then there are much simpler crates out there. ansi_term is the one that the ecosystem has rallied around AIUI.

But yeah, if you aren't using this and there's no use case for it, then I'm going to close it. But if folks want to argue in favor of something like this, there are some thorny issues involved. And personally, I'm not a huge fan of adding more API complexity with global switches.

[BurntSushi]

Unfortunately it seems like it was an effort started by somebody who hadn't heard of CLICOLOR and now they want to "win".

FWIW, I don't agree with this characterization of that issue.

[Timmmm]

termcolor's API is more complex out of necessity: it supports the Windows console APIs.

FWIW colored supports Windows too, though I think it might only be recent versions - I assume supporting old versions is where the complexity comes from.

then there are much simpler crates out there. ansi_term is the one that the ecosystem has rallied around AIUI.

I dunno if I'd say it is simpler...

// ansi_term
println!("This is in red: {}", Red.paint("a red string"));
// colored
println!("This is in red: {}", "a red string".red());

But I'll give them points for the British spelling! :-P

I wish someone would make a macro like this:

println_colour!("This is in red: {<red>}a red string{</>}");

You know, syntax bikeshed and everything but it's pretty annoying that you can't just put the colour formatting in the format string.

Anyway! I've wasted enough of your time, bye!

[BurntSushi]

FWIW colored supports Windows too, though I think it might only be recent versions - I assume supporting old versions is where the complexity comes from.

Yes, only recent versions of Windows support terminal colors through ANSI escape codes.

I dunno if I'd say it is simpler...

I didn't say ansi_term was simpler than colored. I was saying that ansi_term was one of many alternatives to termcolor that is simpler than termcolor, principally because it does not satisfy the same requirements as termcolor. I was also saying that ansi_term is one that, AIUI, the ecosystem has rallied around when the requirements met by termcolor aren't needed. That has value.

[Timmmm]

I didn't say...

Oh sorry I misread.