Adding "found" might seem minor but I feel it has a slight softening on the message. It also maintains scanability as it is at the end and short.
As this is a one-off message change and not a styling issue to be consistent with, I think this is safe to put in a patch release.
This let's you get an arguments values, grouped by the occurrence of the
argument.
Note: this does not stablize derive support. That requires a blocking
change and can be enabled via `unstable-v5` flag. See #4626 for an
exploration of how we can make this easier in the future.
Fixes#2924
My guess is this was left over from switching to using the type based
API. The generated code for extracting values from `ArgMatches` had some
code that didn't actually do anything, like mapping over the identity
function, and wrapping a value in an `Ok` only to immediately use "?" on
it.
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>
In text communication you need to balance
- Scannability, putting the most important information upfront
- Brevity so people don't get lost in the message
- Softness to help ease people through a frustrating experience
I feel we weren't doing great on the first two points, so tried to
iterate on the messages to improve them. I hope we aren't suffering too
much on the third point as a side effect.
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
