Re: Bug#252233: zsh: filename completion after long options like --foo=

Re: Bug#252233: zsh: filename completion after long options like --foo=

[Clint Adams]

> > In which specific situation is it not working?
> 
> I suspect --help format is not canonical enough...
> 
> As an experiment, I wrote the following configure script.
> 
> #! /bin/sh
> cat <<'EOF'
> --enable and --with options recognized:
>   --enable-maintainer-mode enable make rules and dependencies not useful
>                           (and sometimes confusing) to the casual installer
>   --with-perl[=FILE]  Perl is needed to compile the description files, but gp2c
>   --with-paricfg[=FILE]  PARI configuration is needed to build plug-ins.
> EOF
> 
> It appears to work w.r.t. zsh completion in woody but not in sid.
> 
> Strangely, both Completion/Unix/_configure are identicals.
> What are the relevant files to look at.

_configure and _arguments, I think.

Re: Bug#252233: zsh: filename completion after long options like --foo=

[Bill Allombert]

Hello,

I can reproduce the problem with a standard configure file:
If a package use gettext (I tried with lostirc), configure says:
./configure --help
...
  --with-libintl-prefix[=DIR]  search for libintl in DIR/include and
  DIR/lib
...
but ./configure --with-libintl-prefix= won't complete on directory.

It works fine with woody zsh 4.0.4.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Re: Bug#252233: zsh: filename completion after long options like --foo=

[Clint Adams]

> I can reproduce the problem with a standard configure file:
> If a package use gettext (I tried with lostirc), configure says:
> ./configure --help
> ...
>   --with-libintl-prefix[=DIR]  search for libintl in DIR/include and
>   DIR/lib
> ...
> but ./configure --with-libintl-prefix= won't complete on directory.

So, if you remove the brackets from that line in ./configure, it works.

Re: Bug#252233: zsh: filename completion after long options like --foo=

[Bill Allombert]

On Wed, Jun 02, 2004 at 05:19:53PM -0400, Clint Adams wrote:
> > I can reproduce the problem with a standard configure file:
> > If a package use gettext (I tried with lostirc), configure says:
> > ./configure --help
> > ...
> >   --with-libintl-prefix[=DIR]  search for libintl in DIR/include and
> >   DIR/lib
> > ...
> > but ./configure --with-libintl-prefix= won't complete on directory.
> 
> So, if you remove the brackets from that line in ./configure, it works.

Yes, but it is highly impractical in this particular case since this
text come from gettext files /usr/share/aclocal/lib-link.m4 and
/usr/share/aclocal/lib-prefix.m4, just grep for "search for".

[] are used to denote optionnal arguments in the help messages.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Re: Bug#252233: zsh: filename completion after long options like --foo=

[Peter Stephenson]

Bill Allombert wrote:
> On Wed, Jun 02, 2004 at 05:19:53PM -0400, Clint Adams wrote:
> > > I can reproduce the problem with a standard configure file:
> > > If a package use gettext (I tried with lostirc), configure says:
> > > ./configure --help
> > > ...
> > >   --with-libintl-prefix[=DIR]  search for libintl in DIR/include and
> > >   DIR/lib
> > > ...
> > > but ./configure --with-libintl-prefix= won't complete on directory.
> > 
> > So, if you remove the brackets from that line in ./configure, it works.
> 
> Yes, but it is highly impractical in this particular case since this
> text come from gettext files /usr/share/aclocal/lib-link.m4 and
> /usr/share/aclocal/lib-prefix.m4, just grep for "search for".
> 
> [] are used to denote optionnal arguments in the help messages.

I don't think editing configure is really an option...

Does the following help?  Calling the code obscure would be an insult to
some perfectly charming obscure features of other languages, and I don't
have a suitable package to test, but in the in the listing for zsh's
configure it seemed to be doing the right thing for
--with-PACKAGE=[ARG].

In case the lines get rewrapped, the change is the addition of an extra ${(@)
near the start of the first altered line, and the addition of //\[=/=}
near the end of the second.

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.15
diff -u -r1.15 _arguments
--- Completion/Base/Utility/_arguments	5 Jun 2003 09:51:32 -0000	1.15
+++ Completion/Base/Utility/_arguments	9 Jun 2004 09:47:25 -0000
@@ -67,9 +67,9 @@
     # those hyphens and anything from the space or tab after the
     # option up to the end.
 
-    lopts=("--${(@)^${(@)${(@)${(@M)${(@ps:\n:j:\n:)${(@)${(@M)${(@f)$(_call_program options ${~words[1]} --help 2>&1)//\[--/
+    lopts=("--${(@)${(@)^${(@)${(@)${(@M)${(@ps:\n:j:\n:)${(@)${(@M)${(@f)$(_call_program options ${~words[1]} --help 2>&1)//\[--/
 --}:#[ 	]#-*}//,/
-}}:#[ 	]#--*}#*--}%%[]	 ]*}:#}")
+}}:#[ 	]#--*}#*--}%%[]	 ]*}:#}//\[=/=}")
 
     # Remove options also described by user-defined specs.
 

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************