On Fri, 18 May 2001, Bart Schaefer wrote:
> zagzig% a=(x y z)
> zagzig% a[(I)q]=W
> zagzig% echo $a
> x y W x y z

I patched this in a similar way to your diff, but I also made a[(I)q]=W
prepend the 'W' to the array.

> x y W x y z V		<-- this is ok
> zagzig% a[(R)q]=U
> zagzig% echo $a
> U y W x y z V		<-- this is probably unexpected

This is because we currently have a[0] as an alias for a[1].  Did we
have a good reason for that?  I think it would make more sense to have
a[0] return an empty string, while setting it should prepend an element
to the array.  My appended patch goes this route.

> Well, whaddya know; you CAN do an "unshift", you just have to use a
> seemingly-impossible range to accomplish it.

You can also insert a new element anywhere with something like
"a[3,2]=middle".  I think that this is a good thing.

> zagzig% a=(a b c)
> zagzig% a[2,(R)q]=x
> zagzig% echo $a
> a x a b c

Yeah, that's really non-intuitive, isn't it?  You actually told zsh that
you wanted all elements before 2 ("a") before the new string, and all
the elements after 0, ("a b c") after the string.  I think that this
should work the same as a[2,1] -- i.e. it should insert the string
without duplicating any existing elements.  My patch also does this.

If we decide that changing a[0] is a bad idea, I can change $a[(R)q]
to return an empty string when there is no match (rather than the first
element of the array), and I could even make "a[(R)q]=prepend" work
without affecting "a[0]=newfirstelement".  I had such a patch all worked
up when I decided that a[0] should just behave consistently no matter
where the 0 came from.

Thoughts?

..wayne..