Commit graph

88 commits

Author SHA1 Message Date
Ed Page
953e2dcd34 docs: Remove remaining references to clap attribute 2023-02-18 18:42:07 -06:00
Martin
704d0e7a4f chore: Make format!() calls more readable 2023-01-29 19:14:47 +00:00
Ed Page
162a556dba fix(error): Try to soften unexpected argument/value errors
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.
2023-01-13 21:29:49 -06:00
Ed Page
762b06fba4 fix(error): Try to polish/clarify messages
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.
2023-01-06 17:01:36 -06:00
Ed Page
68a7740fdc fix(error): Match rustc for giving more information 2023-01-03 13:22:35 -06:00
Ed Page
c2efb60a5f fix(error): Lowercase the start of error messages
This matches the rustc error style
2023-01-03 13:17:46 -06:00
Ed Page
e7d58b3daf
Merge pull request #4385 from epage/errors
fix(error): Be consistent with rustc diagnostic guidelines
2023-01-03 12:54:16 -06:00
Ed Page
36bc641648 fix(help): Remove extraneous text from built-ins
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
2023-01-03 11:02:26 -06:00
Ed Page
f1ffc63a79 fix(error): Be consistent with rustc diagnostic guidelines
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
2022-10-13 14:01:49 -05:00
Ed Page
f8053fcedb fix(error): Don't suggest '--' when it doesn't help 2022-10-13 10:17:11 -05:00
Ed Page
5399f49572 fix(error): Quote literals consistently 2022-09-29 08:54:03 -05:00
Ed Page
99dfe7404a docs(ref): Remove dead example
This was missed in the migration to the reference being on docs.rs.  Not
feeling its worth finding a way to integrate it into the new structure.
2022-09-21 11:02:08 -05:00
Ed Page
0184cf008a fix(parser): Quote the suggested help
We do it elsewhere but here it is only distinguished coloring.

Inspired by #4218
2022-09-15 16:24:59 -05:00
Ed Page
b7d13dfb88 fix(parser): Prefer invalid subcommands over invalid args
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
2022-09-15 10:30:03 -05:00
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
0e915e0d3a docs(derive): Update for new attributes 2022-09-02 15:39:13 -05:00
Ed Page
5112372c77 feat(parser): Provide convenience for SetTrue
I wanted to make `bool` a defaulted type parameter but
https://github.com/rust-lang/rust/issues/36887
2022-09-01 19:40:56 -05:00
Ed Page
671914b590 fix(error): Make whitespace consistent with self/help
Sometimes errors would use a tab, sometimes four spaces.  This makes it
always four spaces and shares a definition with help.
2022-08-31 16:02:14 -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
0c9b9d7ec8 fix(parser): Show all required errors at once
This also has the side effect of always using the "smart usage" which is
why the tests changed.
2022-08-29 19:40:35 -05:00
Ed Page
83d6add9aa fix(help): Shift focus to subcommands, when present
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.
2022-08-26 10:59:40 -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
85f541d789 fix: Switch to owned types
Impact:
- Binary size: 556.6 KiB to 578.4 KiB
- build time: 6.4950 us (7% slower)
- parse time: 7.7256 us
- parse sc time: 8.1580 us (5% faster)

Fixes #1041
Fixes #2150
2022-08-22 14:55:55 -05:00
Ed Page
5f20fe1930 docs: Shift focus from takes_value to actions 2022-07-26 14:50:51 -05:00
Ed Page
6ecb7310a8 fix(derive)!: Remove value_parser/action defaulted attributes 2022-07-22 20:07:47 -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
389ff4ff21 fix(help): Subcommand display order respects Command::next_display_order
Previous behavior:
- They'd be sorted by default
- They'd derive display order if `DeriveDisplayOrder` was set
  - This could be set recursively
- The initial display order value for subcommands was 0

New behavior:
- Sorted order is derived by default
- Sorting is turned on by `cmd.next_display_order(None)`
  - This is not recursive, it must be set on each level
- The display order incrementing is mixed with arguments
  - This does make it slightly more difficult to predict
2022-07-22 15:03:16 -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
d43f1dbf6f docs: Move everything to docs.rs
A couple of things happened when preparing to release 3.0
- We needed derive documentation
  - I had liked how serde handled theres
  - I had bad experiences finding things in structopt's documentation
- The examples were broken and we needed tests
- The examples seemed to follow a pattern of having tutorial content and
  cookbook content
- We had been getting bug reports from people looking at master and
  thinking they were looking at what is currently released
- We had gotten feedback to keep down the number of places that
  documentation was located

From this, we went with a mix of docs.rs and github
- We kept the number of content locations at 2 rather than 3 by not
  having an external site like serde
- We rewrote the examples into explicit tutorials and cookbooks to align
  with the 4 styles of documentation
- We could test our examples by running `console` code blocks with
  trycmd
- Documentation was versioned and the README pointed to the last release

This had downsides
- The tutorials didn't have the code inlined
- Users still had a hard time finding and navigating between the
  different forms of documentation
- In practice, we were less likely to cross-link between the different
  types of documentation

Moving to docs.rs would offer a lot of benefits, even if it is only
designed for Rust-reference documentation and isn't good for Rust derive
reference documentation, tutorials, cookbooks, etc.  The big problem was
keeping the examples tested to keep maintenance costs down.  Maybe its
just me but its easy to overlook
- You can pull documentation from a file using `#[doc = "path"]`
- Repeated doc attributes get concatenated rather than first or last
  writer winning

Remember these when specifically thinking about Rust documentation made
me realize that we could get everything into docs.rs.

When doing this
- Tutorial code got brought in as was one of the aims
- We needed to split the lib documentation and the README to have all of
  the linking work.  This allowed us to specialize them according to
  their rule (user vs contributor)
- We needed to avoid users getting caught up in making a decision
  between Derive and Builder APIs so we put the focus on the derive API
  with links to the FAQ to help users decide when to use one or the
  other.
- Improved cross-referencing between different parts of the
  documentation
- Limited inline comments were added to example code
  - Introductory example code intentionally does not have teaching
    comments in it as its meant to give a flavor or sense of things and
    not meant to teach on its own.

This is a first attempt.  There will be a lot of room for further
improvement.  Current know downsides:
- Content source is more split up for the tutorials

This hopefully addresses #3189
2022-07-19 13:30:38 -05:00
James D. Turner
f94eafbaf7 Clarify in docs that rename_all needs a string literal 2022-07-11 17:59:02 -04:00
James D. Turner
93565c226c Add "" around string literals in derive ref docs
When deriving `ValueEnum` (and possibly in other cases as well), the
attribute is silently ignored if the user leaves off these quotes.
2022-07-11 17:13:06 -04:00
hw-lunemann
7e785ad9d6 Fix spelling of APIs 2022-06-25 00:55:48 +02:00
Ed Page
1ba6ef9080
Merge pull request #3818 from mbhall88/patch-1
docs: update return signature for try_from_os_str
2022-06-13 19:18:39 -05:00
Ed Page
0c367104ae docs(derive): Update deprecation notice 2022-06-13 18:54:43 -05:00
Michael Hall
52403cd8cc
Update README.md 2022-06-14 09:16:52 +10:00
Michael Hall
066c351639
update return signature for try_from_os_str 2022-06-13 11:15:56 +10:00
Ed Page
9caec5a52d fix(parser): Deprecate ArgMatches::is_present 2022-06-10 14:21:25 -05:00
Ed Page
9e38353442 fix(derive): Clarify ArgEnum as ValueEnum
We aren't enumerating arguments but values for an argument, so the name
should reflect that.

This will be important as part of #1807 when we have more specific
attribute names.
2022-06-08 11:14:09 -05:00
Ed Page
647896d929 feat(derive): Expose control over Actions
This is the derive support for #3774 (see also #3775, #3777)

This combined with `value_parser` replaces `parser`.  The main
frustration with this is that `ArgAction::Count` (the replacement for
`parse(from_occurrences)` must be a `u64`.  We could come up with a
magic attribute that is meant to be the value parser's parsed type.  We
could then use `TryFrom` to convert the parsed type to the user's type
to allow more.  That is an exercise for the future.  Alternatively, we
have #3792.

Prep for this included
- #3782
- #3783
- #3786
- #3789
- #3793
2022-06-06 11:35:07 -05:00
Ed Page
b39d3d4f2b docs(derive): Make raw attribute more discoverable
Based on feedback in #3189
2022-05-30 18:41:10 -05:00
Ed Page
fcdd31781b feat(parser): Allow people to plug into 'value_parser' macro
For most users, this won't be worth doing, they can just specify the
parser if needed.  Where this has value is crates that integrate custom
types into clap, like creating click-like file integration.  See
https://click.palletsprojects.com/en/8.0.x/arguments/#file-arguments
2022-05-25 14:12:27 -05:00
Ed Page
177511dab1 fix: Deprecate validator / validator_os
`validator_regex` is being ignored for now as I await on a comment
period for #3743
2022-05-25 12:57:11 -05:00
Ed Page
eda0ca54c1 fix(parser): Simplify the common getter API
Clap has focused on reporting development errors through assertions
rather than mixing user errors with development errors.  Sometimes,
developers need to handle things more flexibly so included in #3732 was
the reporting of value accessor failures as internal errors with a
distinct type.  I've been going back and forth on whether the extra
error pessimises the usability in the common case vs dealing with the
proliferation of different function combinations.  In working on
deprecating the `value_of` functions, I decided that it was going to be
worth duplicating so long as we can keep the documentation focused.
2022-05-25 10:50:42 -05:00
Ed Page
ed45de2f03 fix(parser): Clean up remove types
The remove functions no longer return `Arc` but the core type, at the
cost of requiring `Clone`.  I originally held off on this
in #3732 in the hope of gracefully transition the derive and requiring
`Clone` would have been a breaking change but when it came to #3734, I didn't
find a way to make it work without a breaking change, so I made it
opt-in.  This means I can force the `Clone` requirement now.

I added the requirement for `Clone` everywhere else in the hopes that in
the future, we can drop the `Arc` without a breaking change.
2022-05-24 16:25:07 -05:00
Ed Page
b3847d12f0 docs(ref): Update for _ref derive 2022-05-24 14:53:08 -05:00
Ed Page
33e94df212 docs(example): Update for value_parser 2022-05-24 14:53:08 -05:00
Ed Page
e23800e10e doc(derive): Update for value_parser 2022-05-20 20:02:23 -05:00