Re: [frederik@xxxxxxxxxxxxxxxx: Bug#236748: zsh: associative array documentation reference broken]

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:
> On Mar 8, 10:23am, Clint Adams wrote:
> }
> }  For associative arrays, `[*]' or `[@]' evaluate to all the values
> }  (not the keys, but see Subscript Flags below), in no particular
> }  order.
> } 
> } There is nothing relevant to this syntax under Subscript Flags.
> 
> Yes, there is.  The k, K, and e subscript flags all affect the
> intepretation of * and @.  It's true that [(K)*] is nearly the same
> as [*], but [(k)*] is quite different, as both [(k)@] and [(K)@] are
> from [@].

Yes, I mentioned this in the original thread
(http://bugs.debian.org/236748), though I didn't check which flags
apply.

> }  For associative arrays, `[*]' or `[@]' evaluate to all the values
> }  (not the keys, but see the documentation for the 'k' flag under
> }  Parameter Expansion Flags in zshexpn(1)), in no particular order.
> 
> No, this is NOT what it should say, or at least not ALL that it should
> say.

I think the change as currently proposed is an improvement because it
is far easier to remember (k) and (v) as the way to control whether
keys or values are output. So the emphasis should be on the expansion
flag but it might be useful to mention the subscript flags too.

I've been meaning to make (k) and (kv) work for normal arrays too. The
subscript flags do too many different things which makes them
complicated to remember. Whether things can be changed in a backward
compatible way, I don't know but in any case changes would probably 
need the long overdue parameter code rewrite. I'll bore you with my
thoughts anyway.

The only unique feature the subscript flags offer is the ability to do
reverse subscripting (i.e. looking things up by value instead of key)
and to use pattern matching instead of exact string matches. Those two
features require just two flags (and even the latter is very similar to
${var:#pat}).

We have (k) and (v) flags to control what is returned and if an array
of results is returned, subsequent array indexing such as [1] and [-1]
would replace the abilities of (i) and (I) to return just highest and
lowest values. That'd be easier to read and easier to remember at the
expense of being more to type.

Oliver