`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`.
When we got #3193, we decided in #3196 that `--help` will give a summary
for other commands (`subcmd --help` in this case) but not show the long
version of the output for that other command.
Now with #3215, I think the case is similar for `--help` not showing the
long version but instead preferring the short version and encouraging
people to run `--version`.
Originally. clap only showed the short version or nothing. This was
changed in #2369 without fanfare to prefer the long version over short.
Now are we preferring short version over the long version always, just
like all other help.
Fixes#3215
This reverts commit 333b993481.
PR #1810's motivation was effectively "this is redundant with `\n`".
That is a fine motivation. Unfortunately, we don't have a way to force
a hard break in `clap_derive`. #2389 should help with this eventually
but we shouldn't hold up 3.0 to get that ready. So in the mean time, we
are restoring `{n}`.
We have #3230 for tracking the re-removal of it.
This allows two overriding args to interact with each other mid-line.
This was broken in 7673dfc / #1154. Before that, we duplicated the override
logic in several places.
Now we plug into the start of a new arg which allows us to do this
incrementally without making the logic complex or inefficient, thanks to
prior refactors.
Fixes#3217
This will have a slight performance hit as `AllArgsOverrideSelf` will
allocate a single-element `Vec` per `Arg`. This can be lessened for
positional and multiple occurrences by shifting those checks up into the
propagation check.
Long term, I'd like to see all of the `Arg`-in-`App` settings switch to
this which will make it easier for callers, like completions and man
pages, to figure out whats going on without duplicating the logic.
Short term, this is motivated by wanting to change the override logic to
accomodated interleaved overrides from #3217. Moving this logic will
make it easier to change the override logic.
This is the logical order people think in terms of (`--foo` comes before
`val` in `--foo val`). This also opens things up for using occurrence
incrementing as a place to handle occurrence transitions, like
overrides.
This makes some naming more explicit and allows us to increment
occurrences before adding values (which is the logical mental order and
allows other improvements).
We were storing data off into the struct, obscuring the direct
relationship between gathering and validating conflicts.
With this, not as much code needs to deal with mutable data
