Adds a setting for both `AppSettings` and an `Arg` method which allows
placing the help text for a particular argument (or all arguments via
the `AppSettings`) on the line after the argument itself and indented
once.
This is useful for when a single argument may have a very long
invocation flag, or many value names which throws off the alignment of
al other arguments. On a small terminal this can be terrible. Placing
the text on the line below the argument solves this issue. This is also
how many of the GNU utilities display their help strings for individual
arguments.
The final caes where this can be hepful is if the argument has a very
long or detailed and complex help string that will span multiple lines.
It can be visually more appealing and easier to read when those lines
don't wrap as frequently since there is more space on the next line.
Closes#427
Issue 420
When value names are use, they will be displayed in help and error
messages instead of the argument name. For example, an argument named
`arg` but with the value name `FILE` will be displayed as `[FILE]`.
Likewise multiple value names will be displayed properly such as `[FILE1] [FILE2]`
Closes#420
When value names are use, they will be displayed in help and error
messages instead of the argument name. For example, an argument named
`arg` but with the value name `FILE` will be displayed as `[FILE]`.
Likewise multiple value names will be displayed properly such as `[FILE1] [FILE2]`
Closes#420
Grammatical pedantry
I originally set out to only change liftimes to lifetimes, but I got a little carried away.
Fear not, I decided to stop myself partially through and actually start using your library!
i.e. assume, option -O set to multiple, and number_of_values(1)
set. And assume a *required* positional argument is also set.
-O some -O other pos
Would fail with pos arg not supplied.
Relates to #415
fix: Stop lonely hyphens from causing panic
The method `starts_with` as implemented for the `OsStrExt2` trait on
`OsStr` assumed that the needle given is shorter than the haystack. When
this is not the case, the method panics due to an attempted
out-of-bounds access on the byte representation of `self`. Problematic
if, say, an end-user gives us `"-"` and the library tries to see if that
starts with `"--"`.
Fortunately, slices already implement a `starts_with` method, and we can
delegate to it.
This *does* create a semantics change: if both `self` and the needle
have length 0, this implementation will return `true`, but the old
implementation would return `false`. Based on the test suite still
passing, acknowledging the vacuous truth doesn't seem to cause any
problems.
Fixes#410
ArgGroups can now be built from standalone YAML documents. This is
labeled as a fix because it should have been the case prior. A
standalone YAML document for a group would look something like
```
name: test
args:
- arg1
- arg2
required: true
conflicts:
- arg3
requires:
- arg4
```
This commit also keeps support building groups as part of a larger
entire App YAML document where the name is specified as a key to the
yaml tree
The method `starts_with` as implemented for the `OsStrExt2` trait on
`OsStr` assumed that the needle given is shorter than the haystack. When
this is not the case, the method panics due to an attempted
out-of-bounds access on the byte representation of `self`. Problematic
if, say, an end-user gives us `"-"` and the library tries to see if that
starts with `"--"`.
Fortunately, slices already implement a `starts_with` method, and we can
delegate to it.
This *does* create a semantics change: if both `self` and the needle
have length 0, this implementation will return `true`, but the old
implementation would return `false`. Based on the test suite still
passing, acknowledging the vacuous truth doesn't seem to cause any
problems.
Fixes#410
Bug fixes, new setting, code clean up, and added support u64::max values per arg
This turned into a little more than just a quick bug fix 😜
Thanks to #409 I've piggy backed on that and added support for > 256 values as well.
There's also just a bunch of code deduping and super small macro cleanups.
After this merges I'll put out 2.0.3
Allow for more than 256 occurrences of an argument.
Hi,
I often use tools with `xargs` and the like, and it's entirely possible to end up with inhumanly long sets of parameters being passed to a command.
Without this fix, the library will panic with an arithmetic overflow in `ArgMatcher#inc_occurrence_of` when the 256th instance of the parameter is accounted for.
Thanks,
