Bug#313175: test case for failing argp

[Daniel Hartwig <mandyke@gmail.com>]

found 313175 2.11.2-10
retitle 313175 argp option OPTION_ARG_OPTIONAL not documented correctly
quit

> There's the two ways of supplying the short option, -r 15 and -r15.
> Thinking about it, I guess it sort of makes sense that the version with
> the space won't work when the value is optional.  Otherwise it can't
> tell if you mean a command line value of "15" together with the default
> value of -r (=10), or whether you wanted to set r to 15.  Perhaps the
> documentation needs to be cleaned up rather than the code?

I agree that optional arguments are too ambiguous when preceded by
white-space; `argp_parse' already works as well as it can in this case
by accepting only `--NAME[=ARG]' and `-CHAR[ARG]' formats (no
white-space) and generating help and usage messages to this effect:

$ ARGP_HELP_FMT=dup-args ./minargp --help
Usage: minargp [OPTION...]
minimal argp test for OPTION_ARG_OPTIONAL.

  -r[COUNT], --repeat[=COUNT]   Repeat the output COUNT (default 10) times
  -?, --help                 Give this help list
      --usage                Give a short usage message
$ ARGP_HELP_FMT=dup-args ./minargp --usage
Usage: minargp [-?] [-r[COUNT]] [--repeat[=COUNT]] [--help] [--usage]


I can't think of any programs that actually permit a white-space
between an option and it's _optional_ argument, so I guess this is
perfectly fine behaviour, except that, as you say, the documentation does
not mention this:

`const char *arg'
      If non-zero, this is the name of an argument associated with
      this option, which must be provided (e.g., with the
      `--NAME=VALUE' or `-CHAR VALUE' syntaxes), unless the
      `OPTION_ARG_OPTIONAL' flag (*note Argp Option Flags::) is
      set, in which case it _may_ be provided.

Now this does not explicitly state that `-CHAR VALUE' is valid for
optional arguments, but to clear this up I think something like:

      ...
      set, in which case it _may_ be provided (however, only with
      the less ambiguous `--name[=VALUE]' or `-CHAR[VALUE]'
      syntaxes).

A better change would involve a longer note explaining why not
to accept white-space before optional arguments.