Add categories to Cargo.toml
Hi! [crates.io now supports categories][categories], which are a curated list
of topics aimed at helping an end-user coming to crates.io looking for
"a crate to do ______".
We're sending pull requests to selected crates to add categories in order to help
populate the categories and seed their usefulness. We've made a guess at the best
category/categories for this crate; if it doesn't fit, please feel free to take
a look at [all the available categories and their descriptions][categories] and
[the slug values that should be specified in your Cargo.toml][slugs] and pick
different ones. If you have a category in mind that isn't available, you can
[send a PR to this file on crates.io][categories.toml] to propose additional
categories.
Crates can have up to 5 categories, and uploading categories to crates.io
currently requires publishing a new version with a cargo nightly from 2017-01-18
or later (it needs to contain [this PR][cargo-pr]).
We've [published a blog post][blog-post] with further details about categories.
The blog post also talks about the new crates.io support for CI badges, which
you may be interested in adding as well.
Please let me know if you have any questions!
[categories]: https://crates.io/categories
[slugs]: https://crates.io/category_slugs
[categories.toml]: https://github.com/rust-lang/crates.io/blob/master/src/categories.toml
[cargo-pr]: https://github.com/rust-lang/cargo/pull/3301
[blog-post]: http://integer32.com/2017/01/20/categories-and-ci-badges.html
Explain how `ArgRequiredElseHelp` and `default_value` interact
When calling the executable without arguments one expects a help message. However, if even one argument has a default value, the validation step of the parser will always see at least one argument, and therefore report success. This effectively disables the settings.
When calling the executable without arguments one expects a help message. However, if even one argument has a default value, the validation step of the parser will always see at least one argument, and therefore report success. This effectively disables the settings.
Specifies that use of a valid [argument] negates [subcomands] being used after. By default
`clap` allows arguments between subcommands such as
`<cmd> [cmd_args] <cmd2> [cmd2_args] <cmd3> [cmd3_args]`. This setting disables that
functionality and says that arguments can only follow the *final* subcommand. For instance
using this setting makes only the following invocations possible:
* `<cmd> <cmd2> <cmd3> [cmd3_args]`
* `<cmd> <cmd2> [cmd2_args]`
* `<cmd> [cmd_args]`
Closes#793
