write_help / write_long_help do not respect Command color settings

[nicklan]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Rust Version

rustc 1.58.1 (db9d1b20b 2022-01-20)

Clap Version

3.1.0

Minimal reproducible code

use std::io;
use clap::{Command, ColorChoice};

fn main() {
    let mut cmd = Command::new("myprog").color(ColorChoice::Always);

    println!("This prints color\n");
    cmd.print_help().unwrap();


    println!("\n\nThis doesn't\n");
    let mut out = io::stdout();
    cmd.write_help(&mut out).expect("failed to write to stdout");
}

Steps to reproduce the bug with the above code

Just run it and see that the first prints color, but the second does not

Actual Behaviour

No color, even though Color.Always is set

Expected Behaviour

Should print color

Additional Context

No response

Debug Output

No response

[epage]

This is expected because we Auto won't be able to detect whether we should print colors, so we print everything unstyled.

[nicklan]

Okay, but I set ColorChoice::Always.

In general it would be nice for an application to be able to render colored help to something other than stdout, which isn't possible today.

Some ideas:

1. Expose the Colorizer (https://github.com/clap-rs/clap/blob/master/src/output/fmt.rs#L9) so users can mimic what print_help does.
2. Provide a write_help_color
3. Add a new argument to write_help to enable/disable color
4. Have write_help at least respect ColorChoice::Always and print color in that case.

[epage]

Have write_help at least respect ColorChoice::Always and print color in that case.

I had been thinking about this and this is one that I don't think we should do. For example, in my applications, I do not rely on clap auto-determining whether color should be shown but instead rely on the concolor_clap crate to decide. So for mine, its always set to Always or Never. The function call needs to be independent of that.

Expose the Colorizer (https://github.com/clap-rs/clap/blob/master/src/output/fmt.rs#L9) so users can mimic what print_help does.

Over time, we do plan to expose Colorizer (its not been polished enough to do so now) and give people more direct control over colors. #3476 (comment) is an example of these plans and relevant issues are

• [modular] Decouple help format from help generation #2914
• [modular] Decouple help generation from clap #2913

[nicklan]

Cool, thanks. Having the direct control would solve this issue.

Not quite clear on why you think having write_help respect ColorChoice::Always is a bad idea? Saying that other systems might try and determine it doesn't make sense. If I say "always do color" then shouldn't clap always do color?

[epage]

When I specify the ColorChoice on the Command, its controlling the output of my errors, help, etc and its being set according to what concolor thinks my terminal is capable of.

If I were to call write_help, it can be for a different terminal and purpose and so setting it for one isn't necessarily relevant for the other.

[nicklan]

I get that for your use case respecting Always would break things, but it seems like you're relying on inconsistent behavior. Sure, it could be that write_help is going somewhere else that doesn't want color, but then you shouldn't ask to always have color :).

But I also know breaking existing things is not always an option, which was why I suggested write_help_color as a way to not break any existing code, but still allow writing colored help somewhere other than stdout.