Making this plural can go either way as
- Clarify it is plural
- This is all really to simulate actually doing subcommands and you only
do one at a time
For now, I lean towards clarifying it is plural
I also tweaked the message to be more consistent with how `--help` and
`-h` describe themselves.
Fixes#4342
In clap v4, we changed the padding from 4 to 2 but we didn't update our
calculation for when to switch to next-line-help as it was a magic
number (we tried to catch all of these).
When updating the tests, we also missed that a test was being wrapped
too narrowly
This was found while discussing #3300
This will fix `clap_derive`s behavior for optional-flattened groups as
it will properly detect when the group is present (#3566).
While I consider this a bug and not part of compatibility guarentees, I
still want to keep in mind user impact which could still prevent this.
Defaults will make the group always-present which has little value and
if anything is relying on this, it is probably an application bug.
If users don't want `wrap_help` feature, they can put newlines in where
needed. Seems odd to support wrapping when the wrap size is fixed. For
those hard coding the lines, this will save them a decent amount of
size.
The writer is less convenient and isn't offering any performance
benefits of avoidign the extra allocations, so let's render instead.
This supersedes #3874Fixes#3873
`clap::Error::raw` was producing ambiguity errors with a default generic
parameter on `clap::error::Error` (which `clap::Error` is a re-export
of).
I tried making `clap::Error` a type alias with a default generic
parameter but that ran into an ambiguity error with `map_err`.
So I'm going ahead and hard coding `clap::Error`. We don't expect
people to change this all that often.
This is a cheap pass at creating this to allow cutting out the cost of
rich error information / programmatic error information.
This cuts about 20 KiB off of the binary.
There is more we could cut out, like collecting of used arguments for
the usage, but I want to keep the conditionals simple.
This makes us accept `str` and not do any allocations at the cost of
panicing if unsupported which I think fits our overall story in trying
to catch development-time errors.
Just having `--help` or `--version` can make us get invalid args instead
of invalid subcommands. It doesn't make sense to do this unless
positionals are used. Even then it might not make sense but this is at
least a step in the right direction.
Unsure how I feel about this being backported to clap 3. It most likely
would be fine?
This was noticed while looking into #4218
This was ported over from the usage parser which modeled after docopt.
We just never got around to implementing the rest of the syntax.
However, when considering this as a standalone feature, an
`arg!(--flag <value>)`, outside of other context, should be optional.
This is how the help would display it.
Fixes#4206
In looking at other help output, I noticed that they use two spaces, in
place of clap's 4, and it doesn't suffer from legibility. If it
doesn't make the output worse, let's go ahead and make it as dense so we
fit more content on the screen.
This is a part of #4132
If short help is too long for the terminal, clap will automatically
switch to next line help. As part of next line help for longs, we add a
blank line between args. This helps make the args clearer when dealing
with multiple paragraphs. However, its not as much needed for short and
subcommands (always short), so now short matches subcommands.
This was inspired by #3300 and a part of #4132
