* tests: adds tests for default values triggering conditional requirements
* fix: fixes a bug where default values should have triggered a conditional requirement but didnt
Closes#831
* tests: adds tests for missing conditional requirements in usage string of errors
* fix: fixes a bug where conditionally required args werent appearing in errors
* tests: adds tests for completion generators
* tests: adds tests for completions with binaries names that have underscores
* fix: fixes a bug where ZSH completions would panic if the binary name had an underscore in it
Closes#581
* fix: fixes bash completions for commands that have an underscore in the name
Closes#581
* chore: fix the category for crates.io
* docs(Macros): adds a warning about changing values in Cargo.toml not triggering a rebuild automatically
Closes#838
* fix(Completions): fixes a bug where global args weren't included in the generated completion scripts
Closes#841
* fix: fixes a println->debugln typo
* chore: increase version
* fix: fixes a critical bug where subcommand settings were being propogated too far
Closes#832
* imp: adds ArgGroup::multiple to the supported YAML fields for building ArgGroups from YAML
Closes#840
* chore: increase version
Fix wrapping bugs
I've been working towards integrating my [textwrap][1] crate and along the way, I found some small problems in the existing `wrap_help` function in clap. I basically added new code that calls both `textwrap::fill` and `wrap_help` and panicked on any difference:
```
fn wrap_help(help: &mut String, longest_w: usize, avail_chars: usize) {
let input = help.clone();
let mut old = help.clone();
old_wrap_help(&mut old, longest_w, avail_chars);
let mut wrapped = String::with_capacity(help.len());
for (i, line) in help.lines().enumerate() {
if i > 0 {
wrapped.push('\n');
}
wrapped.push_str(&textwrap::fill(line, avail_chars));
}
// TODO: move up, This keeps old behavior of not wrapping at all
// if one of the words would overflow the line
if longest_w < avail_chars {
*help = wrapped;
}
if *old != *help {
println!("********************************");
println!("longest_w: {}, avail_chars: {}", longest_w, avail_chars);
println!("help: {:3} bytes: {:?}", input.len(), input);
println!("old: {:3} bytes: {:?}", old.len(), old);
println!("new: {:3} bytes: {:?}", help.len(), help);
println!("********************************");
panic!("bad wrap");
}
}
fn old_wrap_help(help: &mut String, longest_w: usize, avail_chars: usize) {
// ... as before
```
This PR fixes two small problems discovered this way, one of which became #828.
[1]: https://crates.io/crates/textwrap
Before, inserting a newline did not move the prev_space index forward.
This meant that the next word was measured incorrectly since the
length was measured back to the word before the newly inserted
linebreak.
Fixes#828.
Before, wrapping the help text at, say, 80 characters really meant
that every line could be at most 79 characters wide.
Lines can now be up to and including avail_chars columns wide.
If needed, a desired margin or padding can be subtracted from the
avail_chars argument at a later point.
This fixes#827. The problem was that the check `grp.args.contains(&grp.args[i])` was a) trivially fulfilled (of course `grp.args[i]` is contained in `grp.args`) and b) causing an out-of-bounds error, since the indices were taken from `.required.len()`.
With this change the argument in the group will be removed from the list of required arguments, as intended.
* tests: remove unnecessary mut
When building the projec, I was told
warning: variable does not need to be mutable, #[warn(unused_mut)]
on by default
--> tests/macros.rs:39:9
|
39 | let mut app = clap_app!(("app name with spaces-and-hyphens") =>
| ^^^^^^^
* examples: remove unused variable
The inner Some value is not used in the match arm:
warning: unused variable: `local_matches`,
#[warn(unused_variables)] on by default
--> examples/20_subcommands.rs:128:32
|
128 | ("local", Some(local_matches)) =>{
| ^^^^^^^^^^^^^
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.
