From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9983 invoked from network); 31 May 2001 15:21:56 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 May 2001 15:21:56 -0000 Received: (qmail 5522 invoked by alias); 31 May 2001 15:21:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14617 Received: (qmail 5510 invoked from network); 31 May 2001 15:21:47 -0000 From: Sven Wischnowsky Date: Thu, 31 May 2001 17:20:46 +0200 (MET DST) Message-Id: <200105311520.RAA12674@beta.informatik.hu-berlin.de> To: zsh-workers@sunsite.dk Subject: Re: _values' options In-Reply-To: <3B1644FF.C89021F3@u.genie.co.uk> Oliver Kiddle wrote: > _values, currently doesn't handle any of the standard compadd style > arguments. This means that it can't be used from _arguments. Try this > to see why: > _arguments '-a:val:_values -s , value one two three' > > I do actually have a case where _values would be useful from > _arguments. I'm guessing that all it would need is a zparseopts to > throw the options away? Yes, some. It might be possible to pass some of them through to the calls to compadd, as you well know, since: > The other related issue is that _values' -S option is possibly not the > best choice of letter. Ideally, it would be possible to pass _values a > suffix and it would work out when the value being completed is the last > possible value (from the exclusion lists) and then use that suffix. In some cases, yes. I guess I didn't made that because there are so many cases where _values has to use the suffix itself. There it is again... suffix handling, one of the things on the list in my head... Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de