From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9006 invoked from network); 4 Apr 2000 16:03:46 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Apr 2000 16:03:46 -0000 Received: (qmail 7727 invoked by alias); 4 Apr 2000 16:03:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10474 Received: (qmail 7680 invoked from network); 4 Apr 2000 16:03:30 -0000 To: Sven Wischnowsky Cc: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: Re: _arguments questions References: <200004041254.OAA09834@beta.informatik.hu-berlin.de> X-Attribution: adl From: Alexandre Duret-Lutz Date: 04 Apr 2000 17:59:56 +0200 In-Reply-To: Sven Wischnowsky's message of "Tue, 4 Apr 2000 14:54:22 +0200 (MET DST)" Message-ID: User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>> "Sven" =3D=3D Sven Wischnowsky w= rites: Sven> Alexandre Duret-Lutz wrote: [...] >> 1) is there a simplier way to nest `_arguments' ? Sven> I don't see any. Sorry. Adding more syntactic sugar to the Sven> _argument specs to support this doesn't seem worth it unless we = put=20 Sven> it into the . Then it's quite simple (making _arguments Sven> insert the dummy, probably using the option name for it). Isn't the `*pattern::message' spec quite the same ?=20 The `*' or the pattern may also be separated from the message by two or three colons. With two colons the words special array and the CUR=AD RENT special parameter are modified to refer only to the words after the option (with two colons)=20 What we want here is that `words' and `CURRENT' refer to the words after the option, *including the option*.=20=20 Why not a four colons separator ? _arguments -a -b '-c:*::::blah: _arguments -c -d -e' Horrible ! Sven> Should we? I would find this helpfull, since it prevent from writting intermediate functions (and since _argument is *the* easy way to write completion functions, it should better nest without requiring the user to dig the completion system). Another idea: Isn't there a way to make _arguments detect whether it has been nested or not ? (I don't know, maybe when the part of the context is already set ?). Of course this solve only the=20 _arguments nesting problem, not the more general "words and CURRENT=20 include the current option" behaviour. [...] --=20 Alexandre Duret-Lutz