Re: buggy configure completion - when both --enable-foo and --disable-foo are listed

[Vincent Lefevre <vincent@vinc17.net>]

On 2016-08-31 03:03:04 +0000, Daniel Shahaf wrote:
> It thinks --enable-gmp-internals takes an argument.  This seems to
> happen whenever there's an "=" sign on that line of the --help output.
[...]
> Line 143 is in the handling of "--help" parsing.  The other lines look
> for --foo=[…]:… specs.  The pattern in 266/268 appears to match the
> '=' sign even though it's in the second colon-separated field, where it
> doesn't denote a mandatory argument.
> 
> I'm guessing the pattern match on lines 266/268 should be fixed, but I'm
> not sure how.

Another example is the following with autoconf-generated configure:

  --enable-silent-rules   less verbose build output (undo: "make V=1")
  --disable-silent-rules  verbose build output (undo: "make V=0")

Moreover, still with autoconf-generated configure, --enable-*
options always accept an argument. More precisely:

  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]

though actually, one generally doesn't provide one (anyway, one cannot
complete on arguments since one doesn't know what is accepted).

I'd say that the rules should be:

* If one just has the option, e.g.

  --enable-gmp-internals  enable use of GMP undocumented functions [default=no]

  (anything after a space following the option being ignored), the
  completion shouldn't assume that the user will give an argument,
  though he might add one after completing.

* If there is a "=" just after the option, e.g.

  --with-mulhigh-size=NUM internal threshold table for mulhigh

  then an argument is assumed.

* If there is an explicit *optional* argument in the --help output,
  e.g.

  --enable-shared[=PKGS]  build shared libraries [default=yes]
  --enable-static[=PKGS]  build static libraries [default=yes]

  (as generated by libtool), then this should also be taken into
  account, but I think that this should be like in the first case.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)