This was supposed to be captured by a deprecation but
- We missed the deprecation on that line
- I think I've run into issues with deprecations not applying to `use`
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.
This gives users the control over where clap outputs while still getting
colors. For users who want to support old windows versions, check out
`fwdansi` crate.
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
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.
Originally, I saw the ideal as the parent command being isolated from
`#[clap(flatte)]` especially after all of the doc comment
leakage issues. We scaled that back to just `next_help_heading` because
of the issues with settling on a policy and maintenance to cover
everything. When doing `next_display_order`, we decided it would mess
things up too much to isolate it.
With #1807, we instead have been moving towards setting
`#[command(next_help_heading)]` anywhere, we just need to finish working
out how it should work.
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
Since the `name` is changed to be the package name, we can't use it as
(1) its not as predictable and (2) it can lead to conflicts if a
`Parser` is flattened into a `Parser`
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
When I removed these in v5, we didn't have a deprecation approach for
the derive and I didn't want to forget. Now we do have a deprecation
approach and that is the reminder, so we don't need to carry around v5
changes.
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
In reviewing CLIs for #4132, I found some were providing helps on `-h`
vs `--help` and figured that could be built directly into clap. I had
considered not making this hint automatic but I figured the overhead of
checking if long exists wouldn't be too bad. The code exists (no binary
size increase) and just a simple iteration is probably not too slow
compared to everything else.
Fixes#1015
This ensures we don't end up with accidental leading or trailing
newlines due to help template variables not being used when a section is
empty.
This is prep for removing name/version from the default template and is
part of #4132
In switching to title case for help headings (#4123), it caused me to
look at "subcommand" in a fresh light. I can't quite put my finger on
it but "Subcommand" looks a bit sloppy. I also have recently been
surveying other CLIs and they just use "command" as well.
All of them are commands anyways, just some are children of others
(subcommands) while others are not (root or top-level commands, or just
command). Context is good enough for clarifying subcommands from root
commands.
This is part of #4132
The setting was added to resolve#769. The reason it was optional is out
of concern for applications with a lot of positional arguments. I think
those cases are rare enough that we should just push people to override
the usage. Positional arguments are generally important enough, even if
optional, to show.
As a side effect, this fixed some bugs with
`dont_collapse_args_in_usage` where it would repeat an argument in a
smart usage.
As a side effect, smart usage now shows `--` when it should
In surveying various tools and CLI parsers, I noticed they list the
subcommands first. This puts an emphasis on them which makes sense
because that is most likely what an end user is supposed to pass in
next.
Listing them last aligns with the usage order but it probably doesn't
outweigh the value of getting a user moving forward.
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
While `TypedValueParser` will generally make it easier to reuse value
parsers, this was particularly written for flags. Besides having a
concrete API to document, an advantage over `fn(&str) -> Result<bool, E>`
value parsers is you get all of the benefits of the existing value
parsers for environment variable parsing.
The main breakinge change cases:
- `&[char]`: now requires removing `&`
- All other non-ID `&[_]`: hopefully #1041 will make these non-breaking
Fixes#2870
Now that `Id` is public, we can have `ArgMatches` report them. If we
have to choose one behavior, this is more universal. The user can still
look up the values, this works with groups whose args have different
types, and this allows people to make decisions off of it when otherwise
there isn't enogh information.
Fixes#2317Fixes#3748
This is a part of #2870 and is prep for #1041
Oddly enough, this dropped the binary size by 200 Bytes
Compared to `HEAD~` on `06_rustup`:
- build: 6.21us -> 6.23us
- parse: 7.55us -> 8.17us
- parse_sc: 7.95us -> 7.65us
Before we introduced actions, it required specific setups to engage with
claps version and help printing. With actions making that more
explicit, we don't get as much benefit from our multiple, obscure, ways
of users customizing help
Before
- Modify existing help or version with `mut_arg` which would
automatically be pushed down the command tree like `global(true)`
- Create an new help or version and have it treated as if it was the
built-in on (I think)
- Use the same flags as built-in and have the built-in flags
automatically disabled
- Users could explicitly disable the built-in functionality and do what
they want
Now
- `mut_arg` no longer works as we define help and version flags at the
end
- If someone defines a flag that overlaps with the built-ins by id,
long, or short, a debug assert will tell them to explicitly disable
the built-in
- Any customization has to be done by a user providing their own. To
propagate through the command tree, they need to set `global(true)`.
Benefits
- Hopefully, this makes it less confusing on how to override help
behavior. Someone creates an arg and we then tell them how to disable
the built-in
- This greatly simplifies the arg handling by pushing more
responsibility onto the developer in what are hopefully just corner
cases
- This removes about 1Kb from .text
Fixes#3405Fixes#4033
In clap v3, `require_value_delimiter` activated an alternative parse
mode where
- `multiple_values` meant "multiple values within a single arg"
- `number_of_values` having no parse impact, only validation impact
- `value_names` being delimited values
For unbounded `number_of_values`, this is exactly what `value_delimiter`
provides. The only value is if someone wanted `value_name` to be
`<file1>,<file2>,...` which can be useful and we might look into adding
back in.
Alternatively, this could be used for cases like key-value pairs but
that has issues like not allowing the delimiter in the value which might
be ok in some cases but not others. We already instead document that
people should instead use `ValueParser` for this case.
In removing this, we remove points of confusion at how the different
multiple values and delimited value calls interact with each other. I
know I would set `require_value_delimiter(true).multiple_values(true)`
when it turns out all I needed was `value_delimiter(',')`.
This also reduces the API surface area which makes it easier to discover
what features we do provide.
While this isn't big, this is also yet another small step towards
reducing binary size and compile times.
