Add a feature flag to automate Windows coloring

[SergioBenitez]

Add a feature flag to automate Windows coloring

[epage]

imo yansi should do all or nothing. I appreciate that its (mostly) not doing things behind my back. The reason I was interested in yansi compared to termcolor (besides ergonomics) is termcolor half-implements the policy I need and implementing the rest felt like I was working against it rather than with it.

[SergioBenitez]

I think this is a rather special case. I don't want to care about the platform. Right now, I need to care about the platform. I cannot think of a single case where you would not want to write:

if !Paint::enable_windows_ascii() {
    Paint::disable()
}

I appreciate that its (mostly) not doing things behind my back. The

What do you feel it does behind your back?

[epage]

What do you feel it does behind your back?

• --color always would not be respected if yansi does this.
• I already have to maintain my own "disable" tracking that has its own logic, on top of what Pain::disable does (see #17, #18)

[SergioBenitez]

These are fantastic points, @epage! I'll think about this a bit. Perhaps we simply want to try enabling coloring on Windows without disabling them if it doesn't work. Thus, a Paint::disable() always disables, but by default, you get colors on Windows without doing anything. What do you think?

[epage]

Tired of copy/pasting my herding of cats (all of the color use in my applications), I've done some research on where Rust is at wrt to color and have created a prototype with a PoC conversion of termcolor (since it has the most varied use cases). I'd be interested in any feedback on the idea or design!

[SergioBenitez]

v2 (in progress, see v2 branch) automatically enables support on Windows.