Re: zparseopts default associative array

[Sebastian Stark <seb.stark@gmail.com>]

Thanks for your very helpful answer. Is there any chance this gets
implemented one day or do I have to find a workaround? I am facing
changes to some scripts that used -K the wrong way, leading to funny
bugs.

2014-02-13 17:56 GMT+01:00 Bart Schaefer <schaefer@brasslantern.com>:
> On Feb 13,  8:17am, Sebastian Stark wrote:
> }
> } Maybe I misunderstood something, but isn't my example the intended use
> } of -K? Or is the condition "when none of the specs for them is used"
> } really meant like "if one option is given, all other default values
> } are emptied"? How would this make sense?
>
> Yes, it really does mean that the defaults are kept only if NONE of
> the possible options for the array are parsed.  Although it applies to
> the default arrays, the intended usage is really with the =array form
> as in this snippet of Completion/Base/Core/_description:
>
>     gropt=(-J)
>     xopt=(-X)
>     nopt=()
>     zparseopts -K -D -a nopt 1 2 V=gropt J=gropt x=xopt
>
> In this example -V and -J are mutually exclusive.  (There seem to be a
> number of unnecessary uses of -K in the Completion tree.)  Before the
> introduction of -K, gropt and xopt would have been unconditionally
> erased by having merely been mentioned in the zparsopts arguments.
>
> Yes, it would probably make sense for associative arrays if -K retained
> individual elements for associative arrays, but the implementation does
> the equivalent of the whole-array assignment o=(-a foo) for both plain
> and associative arrays because there is no useful way to do individual
> element assignment in the non-associative case.  Unfortunately -K was
> an afterthought added with the minimal possible code changes.