Specify default text for optional arguments in help

[emilazy]

Describe your use case

Often, the default values of arguments are determined based on runtime computation, e.g. a --threads parameter defaulting to the number of available threads on the system, or a --config option defaulting to an OS-specific path in the user's home directory (e.g. $XDG_CONFIG_HOME/app-name/config.ron on Linux). It's beneficial for usability to be able to summarize the default arguments, e.g. Number of threads to use [default: # of threads on system] or Path to configuration [default: $XDG_CONFIG_HOME/app-name/config.ron].

At present, there's no API to give a (purely cosmetic) default option text for an optional argument.

Currently, I just do:

#[derive(Clap)]
struct Opts {
    /// Option description [default: $XDG_DATA_HOME/...]
    pub path: Option<PathBuf>,
}

but this isn't quite correct (e.g. it doesn't format the default with Colorizer::good).

Arguably this is an X-Y problem and the real feature request is for "computed defaults" (related to #1694), but I think even with such a mechanism there's value in being able to summarize the default path (rather than e.g. inlining volatile variables like $XDG_RUNTIME_DIR in the help text).

Describe the solution you'd like

#[derive(Clap)]
struct Opts {
    /// Option description
    #[clap(default_help = "$XDG_DATA_HOME/...")]
    pub path: Option<PathBuf>,
}

[pksunkara]

I actually removed the colorizing for default values in #1824. I wanted to rethink quite a bit on how to display all kinds of things like these. But, it's for v3.1

[epage]

One proposal for #2389 includes exposing some level of styling to the user.

#3008 explores pulling defaulting logic out of the core of clap into helpers that you can pass into App and Arg. #3321 then brings up the idea of those traits offering a hint(&self, app: &App) -> Option<&str> function. This would allow creating a no-op default trait impl that just adds information to the help.

Since both of these are not solid enough as alternatives yet, still keeping this open to ensure the use case gets covered by something

[9999years]

It sounds like there's interest for this, so I might prepare a PR.

Related issues:

• Default display for String is awkward, ie [default: ] #4976 (default text could be used to work around bad quoting for values like the empty string)
• Support non-Display types with default_value_t #4558 (default text could be supplied to support non-Display default values)