Commit graph

54 commits

Author SHA1 Message Date
Ed Page
c90a4eabae fix(help): Make output more dense
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
2022-09-07 17:13:55 -05:00
Ed Page
9a645d2d19 fix(help): Collapse usage to one line
After looking at more examples, I've become more attached to this
briefer format.

Part of #4132
2022-09-07 11:03:57 -05:00
Ed Page
1258f3e5f6 fix: Deprecate Command::allow_negative_numbers
Better to set on individual args
2022-09-07 07:24:42 -05:00
Ed Page
8ad29ef337 feat: Allow specifying negative nums on Arg, like hyphens 2022-09-07 07:18:19 -05:00
Ed Page
d45e4be14b fix(derive): Deprecate Command::allow_hyphen_values
Fixes #3450
2022-09-06 20:50:09 -05:00
Ed Page
7a2bbca62b fix(derive): Make Command::allow_hyphen_values forward to Arg 2022-09-06 19:41:17 -05:00
Emerson Ford
fd9a5a1d50 fix(parser): Arg::allow_hyphen_values correctly handles long args in first pos
This makes it match up with `Command::allow_hyphen_values` which was the
guiding factor for what the behavior should be.

This supersedes #4039

Fixes #3880
Fixes #1538
2022-09-06 19:41:17 -05:00
Ed Page
bffce7f57a fix: Deprecate Command::trailing_var_arg
Now that we have it on `Arg`, we don't need it on `Command`
2022-09-06 19:41:17 -05:00
Ed Page
65b5b5f7bf fix(help): Remove name/version/author from help
This is to help shorten it and polish it by removing redundant
information.

This is a part of #4132
2022-08-31 15:06:15 -05:00
Ed Page
42c943844c fix(help): Use Command in place of Subcommand
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
2022-08-31 08:53:10 -05:00
Ed Page
02d27b5ce3 fix(usage): Make dont_collapse_args_in_usage the default
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
2022-08-30 16:12:49 -05:00
Ed Page
02db3043e2 fix(help): Consistently use [] for positionals
In the usaeg we use `[]` but in the arg list we use `<>`.
2022-08-29 15:34:30 -05:00
Ed Page
9b23a09f7a fix(help): Don't rely on ALL CAPS for headers
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.
2022-08-26 10:21:18 -05:00
Ed Page
f70ebe89a7 fix!: Require explicit help/version disabling
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 #3405
Fixes #4033
2022-08-10 20:33:21 -05:00
Ed Page
85ad452c9b fix!: Remove Arg::rwquire_value_delimiter
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.
2022-08-03 21:26:36 -05:00
Ed Page
ba15b5f430 fix!: Rename Arg::number_of_values to Arg::num_args 2022-08-03 14:45:47 -05:00
Ed Page
0664c6db37 fix!: Remove Arg::use_value_delimiter in favor of Arg::value_delimiter 2022-08-03 11:15:29 -05:00
Ed Page
470531b515 fix!: Replace multiple_values with number_of_values
This reduces ambiguity in how the different "multiple" parts of the API
interact and lowrs the amount of API surface area users have to dig
through to use clap.

For now, this is only a matter of cleaning up the public API.  Cleaning
up the implementation is the next step.
2022-08-01 15:50:23 -05:00
Ed Page
76bff6f34e fix!: Remove rest of deprecated APIs
Fixes #4009
2022-08-01 15:21:33 -05:00
Ed Page
355a8ff90c fix!: number_of_values doesn't always imply multiple_values(true)
With `number_of_values` being per-occurrence now, its doesn't make sense
for `number_of_values(0)` to set `takes_value(true)` or for
`number_of_values(1)` to set `multiple_values(true)`.

In addition, an assert is made if the user works around this
2022-07-28 14:40:58 -05:00
Ed Page
5f20fe1930 docs: Shift focus from takes_value to actions 2022-07-26 14:50:51 -05:00
Ed Page
8ea1e2d4d3 fix!: Use value parsers for external subcommands
This changes the default type as well to encourage preserving the full
information for shelling out.  If people need UTF-8, then they can
change the value parser.

Fixes #3733
2022-07-25 14:31:56 -05:00
Ed Page
11076a5c70 fix(help)!: Make DeriveDisplayOrder the default, removing it
Force sorting with `next_display_order(None)`

Fixes #2808
2022-07-22 15:52:03 -05:00
Ed Page
8b064cfee9 fix(derive): Move off of SubcommandRequiredElseHelp
This also let us remove the deprecated attribute

Fixes #3280
2022-07-22 12:33:31 -05:00
Ed Page
0d459128d7 fix(error)!: Merge UnrecognizedSubcommand into InvalidSubcommand
Fixes #3676
2022-07-22 12:12:35 -05:00
Ed Page
01a3ea425f fix!: Remove unstable-v4 feature gate 2022-07-22 11:34:06 -05:00
Ed Page
d7618c79af fix!: Remove args_override_self 2022-07-21 15:45:12 -05:00
Ed Page
9caec5a52d fix(parser): Deprecate ArgMatches::is_present 2022-06-10 14:21:25 -05:00
Ed Page
dffd7932b3 fix(assert): Check for version if user specifies ArgAction::Version 2022-06-08 11:59:49 -05:00
Ed Page
4a9c4dee64 refactor(test): Make it easier to fork tests 2022-06-07 16:21:12 -05:00
Ed Page
1428785677 fix(parser): Deprecate args_override_self
This shouldn't be needed anymore now that this is effectively the new
behavior for the non-deprecated actions.

This was briefly talked about in
https://github.com/clap-rs/clap/discussions/2627 but I wasn't familiar
enough with the implementation to know how safe it is.  Now, maintainrs
and users can be more confident because they are explicitly opting into
it.

See also #3795
2022-06-06 14:57:24 -05:00
Ed Page
f082f499ea fix: Remove deprecation warning 2022-05-26 15:52:35 -05:00
Ed Page
a712adefcd fix(parser): Deprecate value_of and friends 2022-05-25 12:57:11 -05:00
Ed Page
256643f8d3 fix: Deprecate possible_values 2022-05-25 12:57:11 -05:00
Ed Page
20ff4ce05a doc(parser): Document external subcommand escaping behavior 2022-05-06 12:38:23 -05:00
Ed Page
03f132129b fix(parser): Always put in arg "" for external subcommands (unstable)
This allows distinguishing external subcommands from built-in
subcommands which can especially be confusing when escaping subcommands.

Fixes #3263
2022-05-06 12:25:20 -05:00
Ed Page
7cdce9cabe refactor(test): Use snapbox's diffs 2022-04-29 15:32:25 -05:00
Ed Page
a484f622de fix(validate): Overrides always ignore required
Before, if two arguments were required *and* overrode each other, then
`cmd --opt=1 --other=2` succeded but `cmd --other=2` failed despite
ignoring `--opt=1`.  Requiring `--opt=1` to be present but unavailable
doesn't help anyone and makes the behavior less predictable.

Now both commands will have the same behavior.
2022-04-21 15:23:05 -05:00
Ed Page
8f182067e3 feat(clap): Publicly expose Command::build
`Command::_build_all` started as an internal function for
`clap_complete` as a stopgap until #2911.  Overtime, we've been finding
more cases where this function needs to be called, so now we're going to
fully embrace it until #2911 so people aren't scrared off by the hidden
implementation from using it.

This was inspired by #3602

Comptibility: Though this adds a deprecation which we general reserve
for minor or major versions, this is enough of a corner case that I'm
fine doing this in a patch release.
2022-04-19 10:13:43 -05:00
Ed Page
e8010e79a9 refactor: Update app variables to cmd 2022-02-14 15:55:56 -06:00
Ed Page
c4144d7d6c docs: Update App references to Command 2022-02-14 15:33:49 -06:00
Ed Page
4895a32e81 fix: Deprecate SubcommandRequiredElseHelp
Now that we can use `SubcommandRequired |
ArgRequiredElseHelp`, this setting offers little value but requires we
track required subcommands with two different settings.  Deprecating as
the cost is not worth the benefit anymore.

Issue #3280 will see the derive updated
2022-02-11 15:31:25 -06:00
Ed Page
e8e469178c fix(validate): Give precedence to ArgRequiredElseHelp 2022-02-11 14:59:52 -06:00
Ed Page
06d43a02da fix(help): Subcommand help looks like --help
Like was said in #2435, this is what people would expect.

While we should note this in a compatibility section in the changelog, I
do not consider this a breaking change since we should be free to adjust
the help output as needed.  We are cautious when people might build up
their own content around it (like #3312) but apps should already handle
this with `--help` so this shouldn't be a major change.

We aren't offering a way for people to disable this, assuming people
won't need to.  Longer term, we are looking at support "Actions" (#3405)
and expect those to help customize the flags.  We'll need something
similar for the `help` subcommand.

Fixes #3440
2022-02-11 12:47:34 -06:00
Ed Page
272f840178 feat: Replace core set of AppSettings with functions
This is a part of #2717

Some settings didn't get getters because
- They are transient parse settings (e.g. ignore errors)
- They get propagated to args and should be checked there

`is_allow_hyphen_values_set` is a curious case.  In some cases, we only
check the app and not an arg.  This seems suspicious.
2022-02-11 12:35:09 -06:00
Ed Page
9bd7060089 fix: Deprecate various APIs
- ArgSettings are part of #2717
- Errors are part of #2628
- `help_heading` is part of #1807 and #1553
- Some misc parts are for API consistency
2022-02-10 19:37:47 -06:00
Ed Page
47d76742eb feat: Add Arg getters for all settings
This is prep for #2717
2022-02-10 10:18:41 -06:00
Ed Page
b2d1ebef4b fix(help): ArgsRequiredElseHelp should ignore defaults
Fixes #1264
2022-02-08 12:34:19 -06:00
Ed Page
b538a43961 refactor(error): Switch to error::ErrorKind 2022-02-02 15:41:24 -06:00
Ed Page
4538d618a7 refactor: Migrate off of .kind 2022-02-01 11:27:08 -06:00