In some sophisticated situations, these may be expensive to calculate.
One example might be a '--branch' option accepting any single Git
branch that exists on the remote -- in such a case, the remote would
need to be queried for all possible_values. The cost is ultimately
unavoidable at runtime since this validation has to happen eventually,
but there's no need to pay it when generating help text if
`is_hide_possible_values_set`.
To keep '-h' fast, avoid collecting `possible_values` during '-h'
unless we're actually going to use the values in display.
This optimization is repeated for the manpage renderer.
This is trivially based on the short-circuiting logic at [1], which at
least supports the idea that actually consuming the iterator is not
generally-guaranteed behavior when `hide_possible_values` is set.
Note on the 'expensive' mod: This keeps all the possible_values tests
in one file but allows the entire set of tests to be controlled by the
'strings' feature (which is required to be able to use String rather
than str for each possible value).
[1]: clap_builder/src/builder/command.rs:long_help_exists_
derive arguments like this:
#[arg(long)]
pub flag: bool,
were producing option descriptions like this:
--flag=FLAG
FLAG is spurious. It turns out that derive always sets a value name, for
simplicity, even when there are no arguments. Check for this case.
Fixes#4443.
This is an intermediate solution for #4408. As there were no agreeed
upon goals, I went with what I felt read well and that I saw commonly
used on non-clap commands.
- "information" isn't really a necessary word.
- I originally favored `Print this help` but realied that doesn't read
correctly in completions.
- Besides being shorter, the reason for the flipped short/long hint is
it gives people the context they need for scanning, emphasizing
"summary" and "more".
Fixes#4409
