From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-14228-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 16214 invoked from network); 5 May 2001 00:29:26 -0000
Received: from sunsite.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 5 May 2001 00:29:26 -0000
Received: (qmail 8221 invoked by alias); 5 May 2001 00:29:20 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 14228
Received: (qmail 8205 invoked from network); 5 May 2001 00:29:20 -0000
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
Message-Id: <010504172823.ZM19667@candle.brasslantern.com>
Date: Fri, 4 May 2001 17:28:23 -0700
In-Reply-To: <3AF333EC.7066178F@u.genie.co.uk>
Comments: In reply to Oliver Kiddle <opk@u.genie.co.uk>
        "PATCH: completion for subscript flags" (May  4, 11:57pm)
References: <3AF333EC.7066178F@u.genie.co.uk>
X-Mailer: Z-Mail Lite (5.0.0 30July97)
To: Oliver Kiddle <opk@u.genie.co.uk>, zsh-workers@sunsite.dk
Subject: Re: PATCH: completion for subscript flags
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On May 4, 11:57pm, Oliver Kiddle wrote:
> Subject: PATCH: completion for subscript flags
>
> This adds completion for subscript flags in _subscript so as to further
> reduce the number of times I have to reach for the manual.

Very nice.

> One problem is that _values is not powerful enough to handle the
> arguments such as you have with the s flag (e.g. in $PATH[(s.:.)4]).
> Any ideas on how to handle this or is it not worth bothering?

Hmm.  Something like (this is just meant as example code, not something
that would drop in anywhere):

	[[ $flags = (#b)([snb])(?)(*) ]] && {
	    local f=$match[1] d=$match[2] r=$match[3]
	    [[ $r = (#b)([^$d]##)$d* ]]
	}

> I'd appreciate if someone could check through my descriptions,
> particularly those for associative arrays. I have a suspicion that some
> of the flags aren't working actually but I may just be confused.

I think you've got some of the descriptions wrong.  The wording gets
tricky here.

> +  case ${(Pt)${compstate[parameter]}} in
> +    assoc*) flags=(
> +      '(R k K i I)r[return first matching value]'
> +      '(r k K i I)R[return value of first matching key]'

	'(R k K i I)r[return first value matched by subscript]'
	'(r k K i I)R[return all values matched by subscript]'

> +      '(r R K i I)k[return all values with matching keys]'
> +      '(r R k i I)K[return value of first matching key]'

	'(r R K i I)k[return first value where subscript matched by key]'
	'(r R k i I)K[return all values where subscript matched by key]'

> +      '(r R k K I)i[return first matching key]'
> +      '(r R k K i)I[return all matching keys]'

These are correct, but I'd reword as:

	'(r R k K I)i[return first key matched by subscript]'
	'(r R k K i)I[return all keys matched by subscript]'

The difference is that r and R compare as [[ value = subscript ]] whereas
k and K do [[ subscript = key ]] and i and I do [[ key = subscript ]] --
do you see the analogy to which thing is treated as a pattern?

> +    array*) flags=($flags
> +      'n[specify match to return]'
> +      'b[begin with specified element]'
> +      '(r R k K i)I[reverse subscript giving index of last match]'
> +      '(r k K i I)R[reverse subscripting giving last match]'
> +      '(R k K i I)r[reverse subscripting giving first match]'

You seem to have forgotten

	'(r R k K I)i[reverse subscript giving index of first match]'