Re: Localize MATCH, MBEGIN, etc. in _zstyle and _globquals

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2017-11-02 at 20:09 +0100, Sebastian Gniazdowski wrote:
> On 29 Oct 2017 at 23:07:21, Phil Pennock (zsh-workers+phil.pennock@xxxxxxxxxxxx) wrote:
> > Anyone know of a good reason to not just localize _all_ of the =~
> > non-BASH_REMATCH variables in _main_complete so that they're always
> > isolated to the completion-system, if =~ or -regex-match or -pcre-match
> > is used within the completion system?
> 
> I'm little not current with regex match variables, so not sure what
> you mean by "=~" variables, and why not localize non-BASH_REMATCH
> variables too (or if it's that Zsh code doesn't use them, then it's ok
> for me, logical to not localize them).

I think we've hit an "overly tortured English written by Phil" problem
here.  I _think_ we're pushing for the same goal.

If BASH_REMATCH is not set then various variables are set.  I think
that _all_ of those should always be localized for the completion
system, but was asking if anyone has a convincing reason why not.

The variables are documented in zshmisc(1) in CONDITIONAL EXPRESSIONS
under >> string =~ regexp <<.  Thus:

  local MATCH MBEGIN MEND match mbegin mend


Note re your other point (not quoted by me above): once a variable name
is localized, it's local, and you don't need to force it to be an array
as long as whatever sets it treats it as the right type:

  foo=(alpha beta)
  baz() { foo=(gamma delta); typeset -p foo }
  bar() { typeset -p foo ; local foo; baz }
  bar
  typeset -p foo
  baz
  typeset -p foo

=>

  typeset -g -a foo=( alpha beta )
  typeset -g -a foo=( gamma delta )
  typeset -a foo=( alpha beta )
  typeset -g -a foo=( gamma delta )
  typeset -a foo=( gamma delta )

Thus the variable is always array, but the >>local<< in >>bar()<< works
to protect the global foo.

-Phil