This is carried over from the clap_derive examples. Looking over the
other examples, I feel like they are covered by other examples or by the
derive reference. We should call out deny missing docs though.
This creates distinct tutorial examples from complex feature examples
(more how-tos). Both sets are getting builder / derive versions (at
least the critical ones).
In #27, we removed some default features. When doing so, some places
weren't updated but `doc` feature covered it ... except it was only
partially updated. This makes sure we test all the features.
Too many times people have to disable default features. Let's try to
have a more minimal out of box experience.
- `derive`: people are already used to adding this feature for serde
- `cargo`: not needed for derive
- `env`: most probably don't use this
- `unicode`: most CLIs are probably ASCII. We should do a debug warn
about this though
BREAKING CHANGE: `derive`, `cargo`, `env`, and `unicode` are no longer
on by default.
This ports our example testing over to [trycmd](https://docs.rs/) so
we can:
- More thoroughly test our examples
- Provide always-up-to-date example usage
The old way of testing automatically picked up examples. This new way
requires we have a `.md` file that uses the example in some way.
Notes:
- Moved overall example description to the `.md` file
- I added cross-linking between related examples
- `14_groups` had a redundant paragraph (twice talked about "one and
only one"
2817: Add support for Multicall executables as subcommands with a Multicall setting r=pksunkara a=fishface60
Co-authored-by: Richard Maw <richard.maw@gmail.com>
This is gated behind the `debug` feature flag so only explicit debugging
cases pay the build time and runtime costs.
The builder API's stack traces are generally not too interesting. Where
this really helps is with `clap_derive`. We currently panic on
unexpected conditions which at least gives us a backtrace. We'd like to
turn these into errors but to do so would lose those debuggin
backtraces, which is where this comes in.
This is a part of #2255
This removes the direct dependency on unicode-width and delegates the
complexity of computing the displayed width of text to the Textwrap
crate.
The `display_width` function handles characters like “æøå” (Danish),
“äöü” (German), and “😂✨😍” (emojis) – even if the unicode-width
Cargo feature is disabled.
This is an improvement of the former `str_width` function which would
over-estimate the width of emojis and non-ASCII characters (since they
are several bytes wide).
