From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28954 invoked from network); 8 Jan 2002 15:25:13 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 8 Jan 2002 15:25:13 -0000 Received: (qmail 6544 invoked by alias); 8 Jan 2002 15:25:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16416 Received: (qmail 6523 invoked from network); 8 Jan 2002 15:25:05 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.3824.336821.617178@wischnow.berkom.de> Date: Tue, 8 Jan 2002 16:23:28 +0100 To: zsh-workers@sunsite.dk Subject: Re: _values again and new _ifconfig In-Reply-To: <3C20ABAA.9C04D4D3@yahoo.co.uk> References: <3C20ABAA.9C04D4D3@yahoo.co.uk> X-Mailer: VM 6.95 under 21.5 (patch 3) "asparagus" XEmacs Lucid Oliver Kiddle wrote: > ... > > _ifconfig shows up another limitation of _values. If values are > separated from their arguments by a space (unquoted), it'll go on > completing more values instead of the previous value's arguments. > > What I think is that -S ' ', should mean that the separator is a quoted > space and that with -w, the default for -S should not be '=' but also > separate words. [...] Good idea. No patch for this, though, because it would require quite a bit of coding -- so much that I'm actually reluctant to try it at all. Think about the need to be able to find out which word is a name and which is a value, think about optional values -- that would almost require a re-implementation of the C-core of _arguments. Urgh. It may actually be easier to leave _values for handling only things expressable in a single word and changing _arguments to handle `options' without leading `-'s or `+'s. Or rewrite both of them, based on a bit of common code. Some parsing front ends (one for multiple words, one for a single word) producing the same internal format which is then used by a common back end. Hm. > I also noticed a few cases where the description had been forgotten > from an _values call. I also think it might be better to ditch that > argument to _values and require _description to be used. I made that because that description isn't always needed (not when one of the actions is used) and I wanted to avoid superfluous calls to _description. Bye Sven -- Sven Wischnowsky wischnow@berkom.de