Next-line help for possible values does not feel like its pulling its
weight. If anything we should do next-line help for the entire
argument.
This dropped about 0.5 KiB but more importantly is prep for other
changes.
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
```
This has been implemented for 3 years without much traction for
finishing it up.
The subcommand use case can be worked around by creating `Command`s that
just include the relevant logic, very similar to the default subcommand
examples in `git` / `git-derive`.
Using this for flags is covered by #4793.
Without `unstable-replace` being enabled, this still cut 5 KiB from
`cargo bloat --release --example git`.
Closes#2836Closes#2011
One challenge with this is finding something that generally works.
Making this work perfectly for one setting will make it inconsistent
with other settings and take up more binary size / compile time.
So in the end, I felt like just mirroring rustc (with a bit more
brevity) seemed like a decent experiment. This will be evaluated by the
feedback on release.
This is a small part of #4638
For now, we are still treating `clap` as the user facing API for both
builder and derive, making this an internal change as we don't expect
this to negatively impact builder build times all that much. We can
re-evaluate at a later time and consider having distinct top-level
crates for builder and derive.
Looking at `--timings` on my machine
- `clap` only took 0.04s to build and it happened in
parallel to `clap_builder` codegen
- this saved 1.7s for derive build times, with `clap_builder` building
in parallel to `syn` and `clap_builder` and `clap_derive` finishing
around the same time.
This was discussed some at https://rust-lang.zulipchat.com/#narrow/stream/220302-wg-cli/topic/clap.20build.20times.20and.20.60clap_derive.60.3A.20a.20crazy.20idea
We were accidentally showing long help just because a hidden argument had a description for a possible value. This is most likely to be hit with the derive API as the value descriptions are automatically applied from documentation.
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
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
Similar to
- Listing all required arguments when one is missing
- Listing all possible values when no value is provided
This came up when discussing #3572
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
From
https://rustc-dev-guide.rust-lang.org/diagnostics.html#suggestion-style-guide
> Suggestions should not be a question. In particular, language like
> "did you mean" should be avoided. Sometimes, it's unclear why a
> particular suggestion is being made. In these cases, it's better to be
> upfront about what the suggestion is.
>
> The message may contain further instruction such as "to do xyz, use"
> or "to do xyz, use abc".
Inspired by #2766
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.
When overriding other fields, help or version flag, globals, etc, a user
might not care about the value, so let's ignore the lookup.
Been talking about this for a while but Issue #4367 moved this forward
because there wasn't a good way to handle this without changing
behavior.
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.
