That way, it will run on travis as well, which comes with python 2
by default, and just doesn't have python 3 pre-installed.
It would probably take to much time to install, especially considering
it's super easy to have to script work in both worlds.
Run the python based --release mode tests as well. They are mainly
concerned with user facing messages, which are as important as the
internal tests run `cargo test`.
More about this can be found [here](http://goo.gl/vt07f7).
It's somewhat unnecessary, but I thought it might be good in preparation
for the next commit.
There now is a single method which deals with formatting the
'did-you-mean' message, supporting different styles to cater all the
various needs that have arisen thus far, with enough potential to be
easily extended in future through a little helper-enumeration whose
variants can possibly take values.
*NOTE*: We might still want to have a look at where the did-you-mean
message should be located for best effect.
Related to #103
This is done in preparation for adding suggestions.
**NOTE**: We will now always use the ...
`"\"{}\" isn't a valid value for '{}'{}"`
... format, even though in one occasion, only a ...
`"\"{}\" isn't a valid value for {}{}"`
... format was used.
Hope that's alright and not breaking the world. At least, it doesn't
break any of the existing tests.
Long arguments now have a special case when saying they are unknown, as
we will match it against all known long flags and suggest the best match
to be used instead.
TODO: refactor to just write a suffix with did-you-mean information.
Related to #103
If an argument is not understood as subcommand, but has a
high-confidence match in the list of all known subcommands, we will use
this one to print a customized error message.
Previously, it would say that a positional argument wasn't understood,
now it will say that a subcommand was unknown, and if the user meant
`high-confidence-candidate`.
If the argument doesn't sufficiently match any subcommand, the default
handling will take over and try to treat it as positional argument.
* added dependency to `strsym` crate
* new `did_you_mean` function uses `strsim::jaro_winkler(...)` to look
for good candidates.
Related to #103
* assure `make test` works on OSX as well
* simplified entire makefile, by basically removing sed invocations to
manipulate the Cargo.toml file under source control.
* *works for me* predicate
This should probably be tested on another system as well, just to be
sure it makes sense for everyone.
Allows creating an enum with CamelCase to follow Rust guidelines, but
then will match ascii case insensitive. This means variant
SomeEnum::Emacs would match string "emacs".
Closes#104
Allows new usage strings with value names or number of values. If the
names are consecutive, they are counted to represent the number of
values (if they all have the same name), or if their names are different
they are used as value names.
Closes#98
When using number_of_values() or value_names() you no longer have to set
.multiple(true) unless you want the argument to be allowed multiple
times (i.e. *not* the value, but the argument itself). This means
without multiple(true) set (and assuming 2 values) -o val1 val2 is only
allowed one time, but with multiple(true) set, -o val1 val2 -o val3 val4
is allowed.
Closes#99
