Resolves#5101
- The completion of value enums now displays accurate help text
- This fix encloses help text in single quotes
- Any text after tab is taken as help text
- Comma in help text is not escaped
- This is because the the help text is now treated as literal
- No variable expansion or command substitution in help text
This command cleaned up all the format args,
making code significantly shorter and more readable.
```
cargo clippy --workspace --fix -- -A clippy::all -W clippy::uninlined_format_args
```
zsh completions for commands that have multiple Vec arguments require
special care.
We can have two Vec args separated with a value terminator.
We can also have two Vec args with no value terminators specified
where the final arg uses 'raw' and thus requires '--' to be used.
The 2nd of these scenarios requires special handling to avoid
emitting a duplicate '*:arguments' completion entry.
Currently, the zsh completions generate an error in this scenario:
$ my-app <TAB>
_arguments:...: doubled rest argument definition:
*::second -- second set of of multi-length arguments:
We already use the '-S' option when calling _arguments.
This option makes it so that completion stops after '--' is encountered.
This means that the handling for trailing 'raw' arguments does not need
to specified.
Special-case multi-valued arguments so that we can skip emitting
the final multi-valued argument if a previous multi-valued argument
has already been emitted.
Closes#3022
Signed-off-by: David Aguilar <davvid@gmail.com>
Emit the user-defined value terminator into the zsh completion pattern
to avoid doubled rest-arguments definitions:
$ my-app <TAB>
_arguments:comparguments:325: doubled rest argument definition:
*::second -- second set of of multi-length arguments:
https://github.com/clap-rs/clap/issues/3266#issuecomment-1007901407
noted that including the value terminator is one step towards a
robust solution for handling multiple multi-valued arguments.
This change does not yet handle automatically detecting when a value
terminator is needed, but it does add tests to ensure that
user-specified value terminators are used on zsh.
Related-to: #3022
Signed-off-by: David Aguilar <davvid@gmail.com>
With the previous fixes for #4273 and #4280 in place, it's now easy to
add support for subcommand aliases, which this commit does. This
addresses #4265 for Bash.
This continues the work started with the fix for #4273. There was
another bug caused by using the subcommand names without considering
their position in the argument list. If the user enters `git diff log
<TAB>`, we build up a string that identifies the subcommand. We ended
up making the string `git__diff__log` in this case because we appended
`__log` without considering the current state. Since `git__diff__log`
does not correspond to an actual command, we wouldn't provide any
suggestions.
This commit restructures the code so we walk subcommands and
subsubcommands in `bash.rs`. While walking those, we build up a list
containing triples of the parent `$cmd` name (e.g. `git__diff`), the
current command's name (e.g. `log`), and the `$cmd` for the current
command. We then build the shell script's case arms based on that
information.
We could instead have fixed#4280 by using the second element in the
pair returned from `utils::all_subcommands()` (a stringified list of
the subcommand path) instead of the first one. However, that would not
have helped us solve #4265.
Closes#4280
Early in the Bash-completion script, we build up a string that
identifies the command or subcommand. When we see the top-level
command's name (e.g. `git`) we set the command so far to that
value. We do that regardless of where in the argument list it
appears. For example, if the argument list is `git diff git`, we set
the current command to `git` when run into it the second time. We
therefore suggest arguments to the top-level command afterwards, which
is not correct.
This patch fixes that by also considering the string that identifies
the command so far, so we only set the overall command to `git` if the
command so far is the empty string.
This is actually just a step on the way to getting completion to work
for aliases of subcommands.
Closes#4273
Another step towards #1041
This isn't the long term type for `PossibleValue::help`, I just wanted
to get the lifetime out of the way first before figuring out how help
will work.
multiple_values is now just book keeping for the builder, instead people
should look to actions and `num_args`.
The meaning for it was a little weird anyways.
The only time it won't be initialized is before `_build`. This is possible because
of #4027
I wish I could just put the `expect` inside the call but I'm worried
about allowing people to build stuff on top of clap.
We aren't enumerating arguments but values for an argument, so the name
should reflect that.
This will be important as part of #1807 when we have more specific
attribute names.
`-h` (short help) still shows the same.
This gates it behind an `unstable-v4` feature flag to avoid disrupting users who set the help without knowing where all it shows up (particularly derive users where `ArgEnum` is automatically extracting the help).
Fixes#3312
