`clap_generate` originally intended to be "generate anything". With
`fig`, we already broke one part out. With #3174's man support, we are
also looking at keeping it separate:
- More freedom to iterate on the API
- Uniqueness (and potential weight) of its dependencies
- man generation is normally more for distribution while completions are
a mix of being distributed with the app or the app generating the
completions (which will be exacerbated if we move most completion
parsing logic to be in Rust)
So `clap_generate` is having a lot more limited of a role than the
original name conveys. I worry the generic name will be a hindrance to
people discovering and using it (yes, documentation can help but there
are limits).
I hesitated because we are on the verge of releasing 3.0. However, doing
it even later will be even more disruptive because more people will be
using it (crates.io lists ~70 people using `clap_generate`).
To ease things, we are still releasing `clap_generate` as a wrapper
around `clap_complete`.
In considering potential work for #2683, I realized we might need a type to carry data for
each of the `multiple_values`. `ArgValue` works both for that and for
possible values, so we need to come up with a better name for one or
both. Changing `ArgValue`s name now would be ideal since its new in
clap3 and by renaming it, we can reduce churn for users.
While thinking about this, I realized I regularly get these mixed
up, so renaming `ArgValue` to `PossibleValue` I think will help clear
things up, regardless of #2683.
This is a followup to #2721 where we decided to remove all of the
helpers from the trait. They are now in a `utils` mod. A part of me
wants this module to be private but it'd be a lot to duplicate for the
split out modules.
Note: this doesn't update fig. Fig was never added to the workspace and
is already broken (and not just from #2721). My plan is to get this
merged and then fix Fig, rather than fix it in multiple passes.
* feat(arg_value): ArgValue can be used for possible_values
Through the ArgValue it is possible:
* `hide` possible_values from showing in completion, help and validation
* add `about` to possible_values in completion
* Resolved a few change-requests by epage
* make clippy happy
* add ArgValue::get_visible_value
* remove verbose destructering
* rename ArgValue::get_hidden to ArgValue::is_hidden
* add test for help output of hidden ArgValues
* Documentation for ArgValue
There is an issue that required to implement From<&ArgValue> for
ArgValue. We should probably find a solution without that.
* fix requested changes by epage
* fix formatting
* add deref in possible_values call to remove From<&&str>
* make clippy happy
* use copied() instad of map(|v|*v)
* Finishing up for merge, hopefully
* changes requested by pksunkara
Following changes are implemented:
- Add 'clap::Arg::get_visible_aliases(&self)' method
This new method provides access to visible argument aliases
- Add 'clap::Arg::get_short/long_and_visible_aliases
This new method provides access to the short/long arguments and its
visible aliases
- Add visible aliases completions in clap_generate for following shells:
- Bash
- Elvish
- Fish
- Powershell
- Zsh
- Add test fixtures for testing visible alias completions in clap_generate:
'clap_generate/tests/completions/<shell>::<shell>_with_aliases()'
compgen takes exactly one "word" argument; if multiple are passed, it
will ignore all but the first. If `$cur` is not quoted and contains
whitespace, it will be expanded into multiple words, so the completions
will be based only on the first word of `$cur`, which is clearly not
correct.
To fix this, quote `$cur` to prevent word splitting, where necessary
(Bash does not perform word splitting inside the extended test command
`[[`, so quotes aren't necessary there).
