From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17359 invoked from network); 5 Mar 1999 11:14:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Mar 1999 11:14:14 -0000 Received: (qmail 11229 invoked by alias); 5 Mar 1999 11:13:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5652 Received: (qmail 11222 invoked from network); 5 Mar 1999 11:13:46 -0000 Date: Fri, 5 Mar 1999 12:13:02 +0100 (MET) Message-Id: <199903051113.MAA03872@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Fri, 5 Mar 1999 12:41:58 +0300 Subject: Re: PATCH: zsh-3.1.5-pws-10: _configure completion Andrej Borsenkow wrote: > This patch tries to be a bit smarter. > > - it is using matching control, so --e-z-m completes to --enable-zsh-mem* > - it tries to guess (basing on --help output) if parameter takes an argument > and appends ``=''. If argument is indicated as optional, ``='' is > autoremoved. I've been thinking about this yesterday evening. Shouldn't we try to write a helper function `_gnu_options' or something like that? This function would use `--help' to get the list, automatically detect `FILE' and `DIR' to use `_files' or `_files -/' and things like that. It could also use `_comp_parts' to complete `--foo=y' to `--foobar=yes' and things like that (we may want to give it options that say which strings to complete after certain option, based on option name or on the string that appears in the output of `--help' after the equal sign). We probably should make it return a value that indicates if options were completed and otherwise make it skip over the options and report the resulting position, so that `_tar' can easily be changed to support long options *and* in-tar-completion. Then we could use that function in `_tar', `_configure', and `_a2ps' and probably in a new `_gnu_command' function. > ------=_NextPart_000_000E_01BE6705.8F107370 > Content-Type: application/octet-stream; > name="_configure.patch" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="_configure.patch" Ugh. Couldn't we try to avoid using MIME for patches, please? Using my self-written Emacs-based mail reader I never had problems with this list and I really don't feel like starting up netscape or some such horror just to get at a patch. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de