Localize MATCH, MBEGIN, etc. in _zstyle and _globquals

Localize MATCH, MBEGIN, etc. in _zstyle and _globquals

[Sebastian Gniazdowski]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Hello,
I was searching for regex usage (=~) and didn't find anything meaningful (would replace with (#b) or (#m) so that e.g. default static build works fine). However found (#m) use and not defined local MATCH, MBEGIN, MEND. To not surprise user with overwriting his matching results, I've localized those parameters in two Zsh-related completions.

--  
Sebastian Gniazdowski
psprint /at/ zdharma.org

[-- Attachment #2: local_MATCH.diff.txt --]
[-- Type: text/plain, Size: 855 bytes --]

diff --git a/Completion/Zsh/Command/_zstyle b/Completion/Zsh/Command/_zstyle
index 0e82822..7db73c0 100644
--- a/Completion/Zsh/Command/_zstyle
+++ b/Completion/Zsh/Command/_zstyle
@@ -1,7 +1,8 @@
 #compdef zstyle
 
 local state context ostate line expl ctop suf
-local nm=$compstate[nmatches] taglist patterns contexts
+local nm=$compstate[nmatches] taglist patterns contexts MATCH
+integer MBEGIN MEND
 typeset -A opt_args styles
 
 _vcs_info_hooks() {
diff --git a/Completion/Zsh/Type/_globquals b/Completion/Zsh/Type/_globquals
index c855b54..915f97c 100644
--- a/Completion/Zsh/Type/_globquals
+++ b/Completion/Zsh/Type/_globquals
@@ -1,6 +1,7 @@
 #autoload
 
-local state=qual expl char delim timespec default
+local state=qual expl char delim timespec default MATCH
+integer MBEGIN MEND
 local -a alts tdisp sdisp tmatch smatch
 local -A specmap
 

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

[Phil Pennock]

On 2017-10-29 at 12:40 +0100, Sebastian Gniazdowski wrote:
> I was searching for regex usage (=~) and didn't find anything
> meaningful (would replace with (#b) or (#m) so that e.g. default
> static build works fine). However found (#m) use and not defined local
> MATCH, MBEGIN, MEND. To not surprise user with overwriting his
> matching results, I've localized those parameters in two Zsh-related
> completions.

_main_complete localizes `match` already.  So if we don't localize all
of them in the same place then we're risking inconsistency, no matter
what.

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?

-Phil

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

[Sebastian Gniazdowski]

On 29 Oct 2017 at 23:07:21, Phil Pennock (zsh-workers+phil.pennock@spodhuis.org) wrote:
> _main_complete localizes `match` already. So if we don't localize all
> of them in the same place then we're risking inconsistency, no matter
> what.

Worth noting it doesn't localize $mbegin and $mend. Also, it uses local not local -a for $match, which is a minor thing.

> 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).

-- 
Sebastian Gniazdowski
psprint /at/ zdharma.org

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

[Phil Pennock]

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@spodhuis.org) 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

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

[Sebastian Gniazdowski]

On 2 listopada 2017 at 20:57:26, Phil Pennock (zsh-workers+phil.pennock@spodhuis.org) wrote:
> 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:

Interesting, didn't know it's possible to get full $match, $mbegin, $mend behavior with regular expressions. I'm always striving for (#m) then (#b). I'm just gonna share something that shows that / substitution could allow regex too, in ideal world. So for example I have an array:

list=( 'href="/junegunn/fzf-bin/releases/download/0.17.1/fzf-0.17.1-darwin_386.tgz'
'href="/junegunn/fzf-bin/releases/download/0.17.1/fzf-0.17.1-darwin_amd64.tgz'
'href="/junegunn/fzf-bin/releases/download/0.17.1/fzf-0.17.1-freebsd_386.tgz' )

I get the version by:

list=( "${(uOn)list[@]/(#b)href=?(\/[^\/]##)(#c4,4)\/([^\/]##)*/${match[2]}}" )
-> 0.17.1

I think it has a nice trick with the (#c4,4), to have 4 "/..." blocks, avoiding "awk -F/" etc.

> local MATCH MBEGIN MEND match mbegin mend

I agree on the variables.

> 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:

Yes I knew that, it's just maybe 'nicer' to have them array from the beginning.. I also localize MBEGIN and MEND as integers. Hard choice as either option is logical on its own behalf, but maybe there are some hidden reasons for choosing one of them.

-- 
Sebastian Gniazdowski
psprint /at/ zdharma.org

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

[Bart Schaefer]

On Nov 4,  5:57pm, Sebastian Gniazdowski wrote:
}
} I'm just gonna share something that shows that / substitution could
} allow regex too, in ideal world.

Substitution is *very* tightly connected to the internal glob matcher;
I think it'd be quite a significant refactoring effort to replace that
with calls to the externally-linked regex library -- plus we already
have the PCRE vs. standard regex contortion.  There'd also need to be
different syntax (maybe just another (#) marker would to work) to signal
when you want regex interpretation, etc.

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

[Sebastian Gniazdowski]

On 4 Nov 2017 at 20:03:03, Bart Schaefer (schaefer@brasslantern.com) wrote:
> Substitution is *very* tightly connected to the internal glob matcher;
> I think it'd be quite a significant refactoring effort to replace that
> with calls to the externally-linked regex library -- plus we already
> have the PCRE vs. standard regex contortion. There'd also need to be
> different syntax (maybe just another (#) marker would to work) to signal
> when you want regex interpretation, etc.

I rather cannot dispute, and I expected that code is tightly tied to globbing, but it's just worth mentioning that often, when something isn't done at first attempt, it starts to be viewed as enormously hard. Even documentation update, when someone doesn't last to write the 4 sentences more on the last item, can take months. But here I believe that using regex in / substitution is actually hard.

-- 
Sebastian Gniazdowski
psprint /at/ zdharma.org