Re: Bug in regexp operator when warn_create_global is in effect

[Ronald Fischer <ynnor@mm.st>]

> The main point is to handle cases something like the following, where
> although the variable creation is hidden it's explicitly requested by the
> user:
> 
> fn() {
>    [[ $1 = (#m)${~2} ]]
> }
> 
> That (#m) in the pattern and the fact the pattern is in a function are
> the only relevant facts here.  The (#m) is a request to cause MATCH,
> MBEGIN and MEND to be set by the shell.  Because that's the purpose of
> (#m), you want the warning so as to be able to decide whether those
> variables are to be global or not and resolve between the two with a
> local or typeset -g.
> 
> Your case is different because the use of the variables isn't requested
> by special syntax, it's buried under standard regex syntax, so I've
> fixed it for that one case.  I'm certainly interested in any more like
> this you come up with.

Now I get it! Thanks for the explanation!

This (#m) example makes me think to the following problem (looks like an
opened can of worms): 

Clearly, a user who is aware to the global-vs-local topic will
conciously decide, whether he wants the M* variables local or global,
but no matter how he decides, it would be an insane decision if he
doesn't decide for the same scope on all three variables. For example,
it doesn't make sense to define MBEGIN as global and MATCH and MEND as
local. From the programmer's viewpoint, it would be more natural to
either decide on these three variables "as a group". Either all global
or all local. Currently, there is nothing which would enforce this
decision.

This now looks like a special case for (#m), but I wonder whether the
same wouldn't be true too for zsh modules, which also might create sets
of variables which belong together.

>From a programmer's viewpoint, a good concept (IMHO) would be that these
automatically created variables are always local, so if a function wants
to make a match globally visible, it would have to create its own global
variable for this. In the same way, it would perhaps make sense that
loop variables (in for-loop) are by default local, because this is the
usual way to use them. However, in both cases this might break existing
code, so it is perhaps not a real alternative. Seems that we have to
live with a compromise.

> That's fixed by my patch, as far as I can tell with no collateral
> damage. 

Thanks a lot, really. From which zsh version will this be available?

Ronald