From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18869 invoked from network); 5 Apr 2000 08:12:08 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Apr 2000 08:12:08 -0000 Received: (qmail 16061 invoked by alias); 5 Apr 2000 08:12:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10496 Received: (qmail 16035 invoked from network); 5 Apr 2000 08:12:00 -0000 Date: Wed, 5 Apr 2000 10:11:57 +0200 (MET DST) Message-Id: <200004050811.KAA01592@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Alexandre Duret-Lutz's message of 04 Apr 2000 17:59:56 +0200 Subject: Re: PATCH: Re: _arguments questions Alexandre Duret-Lutz wrote: > >>> "Sven" == Sven Wischnowsky writes: > > 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 > 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 ? > 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­ > RENT special parameter are modified to refer > only to the words after the option (with two > colons) > > What we want here is that `words' and `CURRENT' refer to the > words after the option, *including the option*. > Why not a four colons separator ? > > _arguments -a -b '-c:*::::blah: _arguments -c -d -e' > > Horrible ! Because of that (;-) and because it isn't quite the same (but I confess, I had the same idea...). Especially, adding this dummy element might be useful to combine with both `::' and `:::'. > 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). Hm, yes. I guess many people won't use $words and friends directly... > 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 > _arguments nesting problem, not the more general "words and CURRENT > include the current option" behaviour. This could be easily done by looking at $funcstack. But it would be wrong to do that, I think, because there may be cases where one doesn't want this dummy element and if the nested call to _arguments inserts it automatically one has no way to circumvent it. Unless we add a option to _aguments, but that would be more obscure than adding it to the action of the outer _arguments. Also, only in the outer _arguments can it be decided if we need a dummy element. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de