Re: LOCAL_VARS option ?

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Peter Stephenson wrote on Mon, Jan 23, 2017 at 10:09:14 +0000:
> I've committed this for further examination.

Thanks!  (not only for the patch, but also for the shiny new docstring
it adds)

I'm tempted to add it to zsh-syntax-highlighting as:
.
    setopt localoptions warncreateglobal ${(k)options[(I)warnnestedvar]}
.
which should also work when ${options} is unset and in released shells
that lack WARN_NESTED_VAR.

> > We've got a byte's worth of data with options we could use more
> > expressively anyway.  I think we've vaguely discussed this before.
> 
> This could be done in a fairly non-disruptive way if we ever need it.
> Extend the current syntax to setopt option=(off|on) and allow individual
> options to extend the mapping (off|on|other1|other2).  isset(X) is simply
> (opts[X]) so the extra detail is already there if you want to get it out.

For extensibility, should we make the -W option take an argument?  I.e.,
«functions -W '' foo» instead of «functions -W foo».  We can permit just
one value for the argument for now; the point is to leave room for
future extensions.

> This won't stop the current init trickery with a value of 2 for certain
> existing options which are never going to get public additional values.