Inspired by rust-lang/cargo#12494.
Part of this is that our "did you mean" does prefix checks so it can be
overly aggressive in providing suggestions.
To avoid providing needless suggestions I limited this change to `last`
/ `trailing_var_arg` as those convey that `--` is more likely a valid
suggestion.
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.
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
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
`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.
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
I see them fulfilling two roles
- A form of bolding
- As a callback to their placeholder in usage
However, it is a bit of an unpolished look and no other CLI seems to do
it. This looks a bit more proefessional. We have colored help for
formatting and I think the sections relation to usage will be clear
enough.
For now, there isn't much a custom implementation can do.
Going from `Rich` to `Null` drops about 6 KiB from the binary
This is a part of #1365 and #1384
This is prep for moving the derive tests. Besides organizing the test
folder for each API, this should reduce link time at the cost of
re-compiling more when a test changes.
