Advice on help menu that shows same possible enum values too often

[fritzrehde]

Hi, I'm working on watchbind and recently added a Color enum (wrapper around ratatuis Color type) for better parsing when customizing the style. I also want to show the user all possible values of this color enum in the help menu. However, what I would like to avoid, if possible, is displaying all color enum variants for all cli options that use this color as input. Here is my current -h output:

A CLI menu for periodically watching a program's output and executing commands on its lines through keybindings

Usage:

Arguments:
  [WATCHED_COMMAND]...  Command to watch by executing periodically

Options:
  -l, --log-file <FILE>                 Enable logging, and write logs to file
      --initial-env <LIST>              Command to watch by executing periodically
  -c, --config-file <FILE>              TOML config file path
  -i, --interval <SECS>                 Seconds to wait between updates, 0 only executes once
      --non-cursor-fg <COLOR>           Foreground color of all lines except cursor [default: unspecified] [possible values: white, black, red, green, yellow, blue, magenta, cyan, gray, dark-gray, light-red, light-green, light-yellow, light-blue, light-magenta, light-cyan, unspecified]
      --non-cursor-bg <COLOR>           Background color of all lines except cursor [default: unspecified] [possible values: white, black, red, green, yellow, blue, magenta, cyan, gray, dark-gray, light-red, light-green, light-yellow, light-blue, light-magenta, light-cyan, unspecified]
      --non-cursor-boldness <BOLDNESS>  Text on all lines except the cursor's line are bold [default: unspecified] [possible values: bold, non-bold, unspecified]
      --cursor-fg <COLOR>               Foreground color of cursor [default: unspecified] [possible values: white, black, red, green, yellow, blue, magenta, cyan, gray, dark-gray, light-red, light-green, light-yellow, light-blue, light-magenta, light-cyan, unspecified]
      --cursor-bg <COLOR>               Background color of cursor [default: unspecified] [possible values: white, black, red, green, yellow, blue, magenta, cyan, gray, dark-gray, light-red, light-green, light-yellow, light-blue, light-magenta, light-cyan, unspecified]
      --cursor-boldness <BOLDNESS>      Text on cursor's line is bold [default: unspecified] [possible values: bold, non-bold, unspecified]
      --header-fg <COLOR>               Foreground color of header lines [default: unspecified] [possible values: white, black, red, green, yellow, blue, magenta, cyan, gray, dark-gray, light-red, light-green, light-yellow, light-blue, light-magenta, light-cyan, unspecified]
      --header-bg <COLOR>               Background color of header lines [default: unspecified] [possible values: white, black, red, green, yellow, blue, magenta, cyan, gray, dark-gray, light-red, light-green, light-yellow, light-blue, light-magenta, light-cyan, unspecified]
      --header-boldness <BOLDNESS>      Text on header line is bold [default: unspecified] [possible values: bold, non-bold, unspecified]
      --selected-bg <COLOR>             Background color of selected line marker [default: unspecified] [possible values: white, black, red, green, yellow, blue, magenta, cyan, gray, dark-gray, light-red, light-green, light-yellow, light-blue, light-magenta, light-cyan, unspecified]
      --header-lines <N>                The first N lines of the input are treated as a sticky header
  -s, --field-separator <STRING>        Field separator
  -f, --fields <LIST>                   Field selections/ranges (comma-separated), e.g., `X`, `X-Y`, `X-` (field indexes start at 1)
  -b, --bind <LIST>                     Keybindings as comma-separated `KEY:OP[+OP]*` pairs, e.g., `q:select+exit,r:reload`
  -h, --help                            Print help (see more with '--help')
  -V, --version                         Print version

Any advice on how I could make this less verbose? Does clap have anything built-in to help me? Or are there conventions/best-practices I could follow?
Would love to hear your ideas! Thanks!

[epage]

I would likely hide_possible_values and then manually list them in the after_help

[fritzrehde]

A also don't entirely understand how I am supposed to incorporate after_help into my derive struct. Is there maybe some example online where someone did something similar, that I could look at?

[epage]

How can I convert a PossibleValue to a string exactly?

[PossibleValue::get_name](https://docs.rs/clap/latest/clap/builder/struct.PossibleValue.html#method.get_name

A also don't entirely understand how I am supposed to incorporate after_help into my derive struct.

The derive reference clarifies that any builder method may be used as a derive attribute.

So you can do #[command(after_help = "")] or #[command(after_help = some_func())]

Is there maybe some example online where someone did something similar, that I could look at?

For the exact request of yours? Not that I can think of.

[fritzrehde]

Ok, I think I have understood most steps now. The last thing I don't understand is how to even get the PossibleValue for e.g. my Color type that derives ValueEnum. Do I have to instanciate a Color object and pass that to PossibleValue::<some_function>()?

[epage]

use clap::ValuEnum;

#[derive(ValueEnum)]
struct Color {
    // ...
}

Color::value_variants().map(|v| v.to_possible_value().get_name().to_owned())

[fritzrehde]

Thanks, got it to work how I want it to now!

[fritzrehde]

One last question regarding after_help: The help string I'd generate would indeed be runtime generated, so might have a bit of overhead. Is the function i pass to after_help evaluated only if that after_help is actually needed (so if the user passes -h/--help), or always evaluated?

[epage]

No, it is eagerly evaluated.

[fritzrehde]

Hmm, ok. Do you think it would be (technically) possible for clap to also support passing functions as expr, and then they are only evaluated when needed? I know nothing about procedural macros, so I have no clue how easy or hard it would be to implement something like that.

[epage]

The macro wraps a builder api and that can't handle it. It also is unlikely to matter enough in practice to do so. If it did, you could do the snapshot-codegen approach I mentioned.

[fritzrehde]

Ok, no worries! Thanks for the explanation though.