textwrap is confused by ColoredHelp

[vincentdephily]

This presumably depends on #836

Rust Version

1.25.0

Affected Version of clap

2.31.2

Expected Behavior Summary

Displaying colored help should use the available term_width.

    -f <foo>                        Many colored values make this obvious [default: a]  [possible values: a, b, c, d, e,
                                    f, g, h, i, j]

Actual Behavior Summary

The escape sequences make the String look long to the text wrapper, but not to the user, and the newline arrive long before the visible term_width.

    -f <foo>                        Many colored values make this obvious [default: a]  [possible values:
                                    a, b, c, d, e, f, g, h,
                                    i, j]

Steps to Reproduce the issue

Take this App definition and run it either normally (colored) or piped to cat (non-colored).

    let args = app_from_crate!()
        .global_setting(AppSettings::ColoredHelp)
        .arg(Arg::with_name("foo")
             .help("Many colored values make this obvious")
             .short("f")
             .takes_value(true) 
             .possible_values(&["a","b","c","d","e","f","g","h","i","j"])
             .default_value("a"))
     .get_matches();

[kbknapp]

Sorry for the long wait, I've been out with my day job.

I looks like the unprinted color codes are what's confusing it.

@mgeisler this looks like it might be on your end 😉

[mgeisler]

Hi guys, yeah, that is something textwrap should be able to handle better! Thanks for the great bug report, I've added an issue for it in my tracker: mgeisler/textwrap#140.

[pksunkara]

This is fixed in #1824 because I removed the colors for arg metadata. Re-adding them back will be addressed in #1456. And that should address this properly. Keeping this open until then.

[CreepySkeleton]

The linked textwrap issue has been closed, so this is probably fixed. We would need to check again nonetheless.

[pksunkara]

I removed the colors from being sent to textwrap. That still doesn't solve this issue because we are now not coloring the possible/default values. Let's keep this open until that is fixed.

[epage]

So it sounds like we've implemented a hack (remove coloring) and textwrap has a permanent fix even if we undo the hack.

@pksunkara what would be the reason for keeping this open?

[pksunkara]

I think I wanted this open to give more context for #1456.