From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13620 invoked from network); 24 Mar 2001 16:40:12 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Mar 2001 16:40:12 -0000 Received: (qmail 27272 invoked by alias); 24 Mar 2001 16:39:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13739 Received: (qmail 27251 invoked from network); 24 Mar 2001 16:39:57 -0000 From: "Bart Schaefer" Message-Id: <1010324163741.ZM29217@candle.brasslantern.com> Date: Sat, 24 Mar 2001 16:37:41 +0000 In-Reply-To: <3ABBDD5A.2DA007C6@u.genie.co.uk> Comments: In reply to Oliver Kiddle "return code of _arguments" (Mar 23, 11:33pm) References: <3ABBDD5A.2DA007C6@u.genie.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Oliver Kiddle , Zsh workers Subject: Re: return code of _arguments MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 23, 11:33pm, Oliver Kiddle wrote: } Subject: return code of _arguments } } If my understanding is correct the test [[ $? = 300 ]] after _arguments } is going to be equivalent to the test [[ -n $state ]]? I suggested getting rid of the 300 return code once before. Back in zsh-workers/12475, Sven wrote: > > No. The special return value is used by the wrappers around _arguments > such as _x_arguments. And there we *need* to be able to distinguish > the cases (to keep the special parameters from being reset). > > And anyway, the problem is not with the return value, since, as you > observed, we use $state for tests anyway. The problem is that with > ->state actions _arguments may have to generate matches (the options) > and it can't know if the caller adds more matches. What I wanted is an > easier way for calling functions to distinguish this from the case > where _arguments generates real matches (by executing one of the other > forms for actions). Currently this can be done by relying on the > return value to test if `real' matches (not only options) were > generated and then use $state to find out if a state has to be handled > and *there* use $compstate[nmatches] to find out if options were > completed. If needed, and it is seldom needed because in most cases > the state doesn't have to be handled in a loop. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net