disable substring match on command name

disable substring match on command name

[Amm]

Hello,

I have following line in .zsh (via zsh-newuser-install)
zstyle ':completion:*' matcher-list '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*'


This does substring match on command and filenames.

i.e. if there is command in system say /usr/bin/foobar and I type

$> oob<TAB>

it changes to foobar.

This
 can cause accidental running of some different command if there is 
spelling mistake. (Especially when you are in a hurry). As with spelling
 mistake there is high chance of matching a random command.


What I would like is substring match to work only on file and directory names. (i.e. arguments to command)

I do not want substring match on command.

Please
 suggest how to do it? I searched on Google but could not find anything.
 (Either I dont know right keyword to search or not many want this 
feature)

Amm.

Re: disable substring match on command name

[Bart Schaefer]

On Mar 3,  1:08am, Amm wrote:
}
} zstyle ':completion:*' matcher-list '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*'
} 
} This can cause accidental running of some different command if there is 
} spelling mistake.
} 
} What I would like is substring match to work only on file and
} directory names. (i.e. arguments to command)

Hmm.  The matcher-list style is looked up very early by _main_complete
so details of the context (like whether you are in command position or
in the argument list) are not available.

However, you could use "zstyle -e" to examine a bit more state and set
the matcher-list accordingly.  For (incomplete) example:

  zstyle -e ':completion:*' matcher-list '(( CURRENT > 1 )) && ...'

The difficulty with this is that the quoting to assign to the $reply
array (in the part I elided with "...") gets really complicated.

Fortunately, I thought of a way to make that a little easier, by the
somewhat non-obvious trick of chaining zstyles together.

The format of the zstyle context is freeform (compsys meerly imposes a
standard set of colon-separated components) so we can put some extra
stuff at the front to create a new "style namespace".  In this case I
suggest prefixing with "word-N" where N is the value of $CURRENT.  So
first we modify your matcher-list context like so:

  zstyle 'word-*:completion:*' matcher-list \
    '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*'

Then we introduce a new matcher for word-1, which will be preferred to
the generic word-* context when looked up:

  zstyle 'word-1:completion:*' matcher-list ''

This just says not to use any matcher for the first word.  If you want
to do *some* kinds of matching on the command name (case-insensitivity,
for example) just add those to this style.

Finally we tweak the style that compsys is actually going to look up,
to have it prefix the context with the word position and then look up
the new style:

  zstyle -e ':completion:*' matcher-list \
    'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply'

By stuffing the result of the chained zstyle -a into the $reply parameter,
we satisfy the requirement of "zstyle -e" to pass this back to whatever
actual lookup was done.

And presto, we have different matcher-list styles for the first word
and the rest of the words.

A few remarks for zsh-workers (please follow up there if interested):

It would be useful for "zstyle -e" if the lookup context and style name
were available in parameters.  E.g. the above trick could be made more
generic if one could do

  zstyle -e ':completion:*' matcher-list \
    'zstyle -a "word-${CURRENT}$LOOKUP" "$STYLE" reply'

The example names LOOKUP and STYLE are probably not the best choices.

Additionally, the line number for xtrace is messed up while evaluating
the "zstyle -e" command.  I *think* it ends up being the line number in
the init file (or interpreter line) where the zstyle was declared, but
it is labeled with the name of the calling function.  E.g. output from
_complete_debug:

+_main_complete:160> zstyle -a :completion::complete::: matcher-list _matchers
+_main_complete:5> zstyle -a word-2:completion::complete:: matcher-list reply

Not sure whether anything can be done about that.

Re: disable substring match on command name

[Amm]

> On Mar 3, Bart Schaefer wrote:


>> On Mar 3,  1:08am, Amm wrote:
>> zstyle ':completion:*' matcher-list '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*'
>>  
>> This can cause accidental running of some different command if there is 
>> spelling mistake.
>>  
>> What I would like is substring match to work only on file and
>> directory names. (i.e. arguments to command)


(Snippets Bart Schaefer solution:)

> first we modify your matcher-list context like so:
> zstyle 'word-*:completion:*' matcher-list \
>   '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*'

> Then we introduce a new matcher for word-1, which will be preferred to
> zstyle 'word-1:completion:*' matcher-list ''


> Finally we tweak the style that compsys is actually going to look up,
> zstyle -e ':completion:*' matcher-list \
>   'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply'


Hi,

Thanks a lot for putting a lot of effort here. I appreciate it.

But your solution possible would not work if command is entered
after pipe symbol.

echo 1 2 | sort

In that example sort would NOT be the first word but 4th or 5th.

I have not tried your solution though. And I also find it little
bit hackish.


However I found a better solution after a lot of reading
(this is just my 2nd day learning zsh, so took lots of time)

TIP: I got hint from man page for zstyle tag-order

I removed matcher-list line. And added the following:

zstyle ':completion:*' tag-order '*' '*:-afrr' '*:-aflr'
zstyle ':completion:*:all-files-afrr' matcher 'r:|[._-]=** r:|=**'
zstyle ':completion:*:all-files-aflr' matcher 'l:|=* r:|=*'

First line tells to first run 'normal' tag-order. If a match
is not found run same tags but with -afrr appended to tag and
if match is still not found then run same with -aflr appended.

If zsh is expecting a command then all-files tag does not exist.
Hence matcher style is also not executed. (only normal match is
tried). So it will work even if command is like (echo 1 2 | sort).
zsh knows that after pipe it should be a command.

If zsh is expecting a filename then first it will try normal
match, if no match is found afrr and aflr (tag) matcher.

Hope this helps others who are looking for similar solutions.

(TIP: when zsh is expecting a directory [if its 'cd' command],
all-files tag is not checked. In that case you can use
local-directories tag in same way as all-files tag as above)

Amm

Re: disable substring match on command name

[Bart Schaefer]

On Mar 3,  3:13pm, Amm wrote:
}
} Thanks a lot for putting a lot of effort here. I appreciate it.

You're welcome!

} > On Mar 3, Bart Schaefer wrote:
} > Finally we tweak the style that compsys is actually going to look up,
} > zstyle -e ':completion:*' matcher-list \
} >   'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply'
} 
} But your solution possible would not work if command is entered
} after pipe symbol.
} 
} echo 1 2 | sort
} 
} In that example sort would NOT be the first word but 4th or 5th.

Just to clear this up:  It would still be the 1st word.  By the time
the $words array has been populated, the completion internals have
figured out that "|" separates two commands and you are presumably
finished completing the one that does not encompass $CURSOR, so it
removes the "|" and everything before it.  In fact, if you had

 echo 2 1 | sort | tr 12 34

and were completing after "sort", it would also remove "| tr ..."
so that $words contains only the relevant command.  None of compsys
would work if every completer had to figure out for itself what to
use for $CURRENT in a pipeline or complex command.

} I have not tried your solution though. And I also find it little
} bit hackish.

Admittedly it is, and in fact I had forgotten that individual "matcher"
zstyles were looked up by tag.  The key bit to your solution is ...

} I removed matcher-list line.

... because matcher-list is applied ALONG WITH the "matcher" style if
both are specified.  There have often been questions in the past about
how to limit the application of matcher-list given how little context
is used, and I found the chaining idea interesting.

} zstyle ':completion:*' tag-order '*' '*:-afrr' '*:-aflr'
} zstyle ':completion:*:all-files-afrr' matcher 'r:|[._-]=** r:|=**'
} zstyle ':completion:*:all-files-aflr' matcher 'l:|=* r:|=*'

It might be worthwhile to note in the docs that matcher-list is in
effect a shorthand for something like this, but I can't find a good
place that doesn't confuse the flow of the existing examples ...

Here, though, is some related clarification of the docs.


diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
index c304461..7dacbcf 100644
--- a/Doc/Zsh/compsys.yo
+++ b/Doc/Zsh/compsys.yo
@@ -1995,11 +1995,11 @@ only be performed with the `tt(*)' inserted.
 kindex(matcher, completion style)
 item(tt(matcher))(
 This style is tested separately for each tag valid in the current
-context.  Its value is added to any match specifications given by the 
+context.  Its value is tried before any match specifications given by the 
 tt(matcher-list) style.  It should be in the form described in
 ifzman(the section `Completion Matching Control' in zmanref(zshcompwid))\
 ifnzman(noderef(Completion Matching Control))\
-.
+.  For examples of this, see the description of the tt(tag-order) style.
 )
 kindex(matcher-list, completion style)
 item(tt(matcher-list))(
@@ -2022,9 +2022,11 @@ without repetition:
 example(zstyle ':completion:*' matcher-list '' '+m:{a-z}={A-Z}' '+m:{A-Z}={a-z}')
 
 It is possible to create match specifications valid for particular
-completers by using the third field of the context.  For example, to
-use the completers tt(_complete) and tt(_prefix) but only allow
-case-insensitive completion with tt(_complete):
+completers by using the third field of the context.  This applies only
+to completers that override the global matcher-list, which as of this
+writing includes only tt(_prefix) and tt(_ignored).  For example, to
+use the completers tt(_complete) and tt(_prefix) but allow
+case-insensitive completion only with tt(_complete):
 
 example(zstyle ':completion:*' completer _complete _prefix
 zstyle ':completion:*:complete:*' matcher-list \ 

Re: disable substring match on command name

[Amm]

----- Original Message -----
From: Bart Schaefer <schaefer@brasslantern.com>

>> But your solution possible would not work if command is entered
>> after pipe symbol.
>> 
>> echo 1 2 | sort
>>  
>> In that example sort would NOT be the first word but 4th or 5th.

> Just to clear this up:  It would still be the 1st word.

Oh that's great. Thanks for clarification.


>> I removed matcher-list line.

> ... because matcher-list is applied ALONG WITH the "matcher" style

Actually it works even with empty matcher-list but then I suppose
no point in keeping it.


> Here, though, is some related clarification of the docs.
> diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo

Is that a proposed diff to doc or you have already added
it? (Dont know if you are one of the developers)

Thanks again,

AMM.

Re: disable substring match on command name

[Bart Schaefer]

On Mar 4, 11:45am, Amm wrote:
}
} > Here, though, is some related clarification of the docs.
} > diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
} 
} Is that a proposed diff to doc or you have already added
} it? (Dont know if you are one of the developers)

I haven't added it *yet*, but I am one of the developers.

Re: disable substring match on command name

[Oliver Kiddle]

Bart wrote:
>   zstyle -e ':completion:*' matcher-list \
>     'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply'

That's very nifty. I wouldn't even call "hackish". You're just allowing
pattern matching to extend to fields that aren't in the standard list.

My only comment is that I'd be inclined to add the custom context
component at the end rather than the beginning.

>   zstyle -e ':completion:*' matcher-list \
>     'zstyle -a "word-${CURRENT}$LOOKUP" "$STYLE" reply'
> 
> The example names LOOKUP and STYLE are probably not the best choices.

How about simply adding an option for chained styles so you might have:
  zstyle -c ':completion:*' matcher-list "word-$CURRENT"
Admittedly, it'd be slightly less flexible.

Oliver

Re: disable substring match on command name

[Amm]

----- Original Message -----
From: Oliver Kiddle <okiddle@yahoo.co.uk>

> Bart wrote:
>>   zstyle -e ':completion:*' matcher-list \
>>     'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply'

> That's very nifty. I wouldn't even call "hackish". You're just allowing
> pattern matching to extend to fields that aren't in the standard list.



Umm, actually I am evaluating which solution would be faster?

Mine OR Bart's?

Then I will switch to one which is faster. (and efficient)


I am not sure how zstyle internally works but let me try.

(Also not sure if this belongs to users maillist or workers)


Case 1:
-------

a) zstyle 'word-*:completion:*' matcher-list \ '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*'
b) zstyle 'word-1:completion:*' matcher-list ''
c) zstyle -e ':completion:*' matcher-list \ 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply'
zstyle pattern matching order, is based on most specific to least specific.

So I think here specific-ness order in this case is b, a, c.



So for each context (not just :completion:) it will:


1) First pattern match with b (which will always fail)
2) Second pattern match with a (again will always fail)
3) Third pattern match with c
   i) Continue to 4) if its :completion: context
  ii) Stop matching

4) Evalute another zstyle (word-1, word-2, ...)
5) When CURRENT is 1, b matches (so just 1 lookup)
   i) Return matcher-list b) arguments
6) When CURRENT is >1, b fails and a matches (so 2 lookups)
   i) Return matcher-list a) arguments
7) Do matcher-list matching as per what is returned by 5 OR 6

Points to note:
Each matcher-list possibly calls matcher internally.

For step 1, 2 pattern match fail on first character (w) itself.
So 1, 2 almost takes not time.

4 = I dont know how expensive evaluate is, it is called every time.

7 = I dont know how expensive reply back is?

One disadvantage is that you can not match context just for files
and directories. Partial match may apply to command arguments,
which may not be what you want.

For e.g ls --li<TAB> will show you
--literal

--dereference-command-line

Possibly there is no way to restrict this.

Case-2:
-------

(Note: I have modified tag-order line a bit to avoid re-checking all tags)

a) zstyle ':completion:*' tag-order '*' 'all-files*:-afrr' 'all-files*:-aflr'
b) zstyle ':completion:*:all-files-afrr' matcher 'r:|[._-]=** r:|=**'
c) zstyle ':completion:*:all-files-aflr' matcher 'l:|=* r:|=*'Here order of checking would be b,c (for matcher style)

So for each context (not just :completion:) it will:

1) Pattern match with a, if :completion: remember tag-order
2) Pattern match with b (will always fail)
3) Pattern match with c (will always fail)
4) Try normal command line completion, if succeeded stop
5) If 1) had matched and tag all-files exist?
   i) NO, then stop
  ii) YES then try tag all-files-afrr (goto 6)
6) Pattern match with b (will always succeed)
7) Check matcher b) arguments, if matched stop, else goto 8
8) Try tag with all-files-aflr
9) Pattern match with b (will always fail)
10) Pattern match with c (will always succeed)
11) Check matcher c) arguments

So steps in this case are higher but its more or less just
string comparison. There is no zstyle evaluation.

One advantage over case 1) is you can match on any tag
(files / directory etc) so you get more flexibility.

You can block matching on aliases / command
options etc. (Unlike in case 1)


So now I am interested in knowing what would actually be
faster? Can there be cases when 1 is faster other is
slower and reverse in some other cases?

Please give your inputs.

Amm.

Re: disable substring match on command name

[Bart Schaefer]

On Mar 4,  4:34pm, Amm wrote:
}
} Umm, actually I am evaluating which solution would be faster?

Yours will probably be somewhat faster but not for the reasons you
worked out.  Looping over the completer list for each element of
matcher-list is going to far outweigh anything else in the process.
Removing the matcher-list style means that _main_complete calls
each function in the completer zstyle only once, then _description
takes just one shot at the matcher style during that iteration.

The advantage of the matcher-list is that you get to try each of the
listed matchers separately.  With the matcher style all combinations
are tried "at once"; in your example you have only one pattern in the
matcher style so this doesn't apply, but in general it may matter.

Hmm, my doc change said the matcher style is "tried before" the
matcher-list if both are used, but that's not quite right; it's tried
"at once" combined with each of the separate matcher-list patterns.
I believe it takes effect first, which may alter the result of the
later patterns but it doesn't stop them being applied.  Hmm.

} I am not sure how zstyle internally works but let me try.

The internal workings of zstyle don't make a lot of difference here,
unless you mean the internal workings of the matcher patterns, which
would depend on what you're completing rather than on which of these
methods you employed.

} (Also not sure if this belongs to users maillist or workers)

Users works fine.  We're not *that* picky unless a long thread about
C programming develops, or something like that.

} 4 = I dont know how expensive evaluate is, it is called every time.

There's a tiny bit of parsing overhead because the string to be eval'd
can't be pre-compiled, but unless you're going to iterate a very large
number of times that won't be signifcant.  Executing the command after
parsing is no more expensive than executing anything else.

} 7 = I dont know how expensive reply back is?

Same as any array assignment, it'll depend on how many elements are
being added to the array.  There's probably one extra array copy in
the case of the "nested" zstyles.

-- 
Barton E. Schaefer

how to truncate an array

[Ray Andrews]

This should be dead simple, but I can't figure out how  to do it. I have 
an array that can be
arbitrarily long, and I want to truncate it at 20 elements.

     setopt POSIX_STRINGS
     string[20]='\0'
     echo "string is now truncated: $string"

... I've tried every variation on the above theme that I can think of 
with no luck.
I know that zsh likes to not truncate strings on 'null' but 
'POSIX_STRINGS' is supposta
force that, no? There must be a simple way to do this. I guess I still 
have C on the brain
but it seems to me that it is God's will that a null terminates a string ...
>

Re: how to truncate an array

[Bart Schaefer]

On Mar 4, 10:04am, Ray Andrews wrote:
}
} This should be dead simple, but I can't figure out how  to do it. I have 
} an array that can be
} arbitrarily long, and I want to truncate it at 20 elements.

Really an array?  Or a string you want to index by character?

    array[21,-1]=()
    string[21,-1]=''

}      setopt POSIX_STRINGS
}      string[20]='\0'

No, that inserted a literal backslash zero into the string.  You meant

    string[21]=$'\0'   # Zsh array indices start at 1, not at 0

but even that doesn't do what you intended because it doesn't actually
insert a NUL into the array, it just deletes the 21st character.
Assigning to string slices with subscript syntax causes the string to
act like an array.  Also, POSIX_STRINGS means that the string $'...'
ends at the NUL, so $'\0' and $'' and $'\0stuff' are all the same.

(Yes, you have C on the brain.  A shell array and a C array are only
loosely related; shell arrays behave more like linked lists.)

Even if it did insert a NUL into the array, the array would't really
be truncated, it's just that this:

}      echo "string is now truncated: $string"

would truncate the quoted portion at the NUL and not show you the rest
of the value of $string.

A side-effect of POSIX_STRINGS is that practically speaking the only
way to generate a NUL byte is to read one from an external program.

Re: how to truncate an array

[Ray Andrews]

On 03/04/2014 10:44 AM, Bart Schaefer wrote:


Bart,

Really an array?  Or a string you want to index by character?

Ahright ... I forgot the rapturous string transubstantiation step:

   array=(${=input_string})
   array[21,-1]=()

... and all is well.

I despair of ever understanding this stuff :-(
God knows what " =() " really does, and I'm smart enough to not even ask ;-)

Re: how to truncate an array

[Bart Schaefer]

On Mar 4, 12:02pm, Ray Andrews wrote:
}
} God knows what " =() " really does, and I'm smart enough to not even ask ;-)

Heh.  () in an assignment is just an array with no elements.

Re: how to truncate an array

[Ray Andrews]

On 03/04/2014 07:05 PM, Bart Schaefer wrote:
> On Mar 4, 12:02pm, Ray Andrews wrote:
> }
> } God knows what " =() " really does, and I'm smart enough to not even ask ;-)
>
> Heh.  () in an assignment is just an array with no elements.
That's easy for you to say. ;-) What I mean is how the underlying C code 
knows to terminate
the array. Come to think of it, there must be a null inserted, cuz 
that's how C does things
even if zsh wants to be different. I wish we could just do the same 
thing up front and in yo' face.
Nevermind, I hafta try to think like a zsheller.
>

Re: how to truncate an array

[J. Darel Henman]

Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 03/04/2014 07:05 PM, Bart Schaefer wrote:
> > On Mar 4, 12:02pm, Ray Andrews wrote:
> > }
> > } God knows what " =() " really does, and I'm smart enough to not even ask ;-)
> >
> > Heh.  () in an assignment is just an array with no elements.
> That's easy for you to say. ;-) What I mean is how the underlying C
> code knows to terminate
> the array. Come to think of it, there must be a null inserted, cuz
> that's how C does things
> even if zsh wants to be different. I wish we could just do the same
> thing up front and in yo' face.
> Nevermind, I hafta try to think like a zsheller.

Ray,
I agree with the recommendation that you stop making assumptions that a shell's method of handilng a particular data structure, is the same as how one of the C language library functions does.  The source code is availabe for you to read and study.  If you come up with a better algorithm I'm sure it would be adopted.  

Thanks

Re: how to truncate an array

[Ray Andrews]

On 03/05/2014 03:02 AM, J. Darel Henman wrote:
> Ray, I agree with the recommendation that you stop making assumptions 
> that a shell's method of handilng a particular data structure, is the 
> same as how one of the C language library functions does. The source 
> code is availabe for you to read and study. If you come up with a 
> better algorithm I'm sure it would be adopted. Thanks 
Pardon. Just musing/speculating out loud. Actually, I am trying to 
remind myself not to think C while at the same time remembering that zsh 
is written in C. It will be a whole long time before I feel competent to 
make any serious suggestions.

Re: how to truncate an array

[Bart Schaefer]

On Mar 4,  9:09pm, Ray Andrews wrote:
} Subject: Re: how to truncate an array
}
} What I mean is how the underlying C code knows to terminate
} the array. Come to think of it, there must be a null inserted, cuz 
} that's how C does things

Zsh does happen to manage shell arrays as C array-of-pointers but as
I said before, in the shell syntax/semantics they function more like
linked lists.  Because the shell language is "higher level" than C,
the internals have to deal with all sorts of other stuff like memory
management.  Bash, for example, does use linked lists internally to
represent arrays.

Re: how to truncate an array

[Ray Andrews]

On 03/05/2014 08:02 AM, Bart Schaefer wrote:
> On Mar 4,  9:09pm, Ray Andrews wrote:
> } Subject: Re: how to truncate an array
> }
> } What I mean is how the underlying C code knows to terminate
> } the array. Come to think of it, there must be a null inserted, cuz
> } that's how C does things
>
> Zsh does happen to manage shell arrays as C array-of-pointers but as
> I said before, in the shell syntax/semantics they function more like
> linked lists.  Because the shell language is "higher level" than C,
> the internals have to deal with all sorts of other stuff like memory
> management.  Bash, for example, does use linked lists internally to
> represent arrays.
>
My talk is just me psyching myself up to build zsh from source and then 
start poking around in the code.
Don't take my ruminations seriously Bart, you have better things to do. 
I'll stop making such remarks
they make me sound bitchy.

Re: disable substring match on command name

[Bart Schaefer]

On Mar 3,  6:25pm, Oliver Kiddle wrote:
} Subject: Re: disable substring match on command name
}
} Bart wrote:
} >   zstyle -e ':completion:*' matcher-list \
} >     'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply'
} 
} My only comment is that I'd be inclined to add the custom context
} component at the end rather than the beginning.

I thought about that, but the tag is already appended with no additional
trailing colon in cases where it is known, and all current zstyle forms
use a leading colon so that seemed the best place to put it.

Also I was a bit worried that :completion:${curcontext}:word-N could
match again the ':completion:*' pattern and put the whole thing into
an loop.  If you stick the word-N on the front, patterns that begin
with ':completion' can't possibly match.
 
} >   zstyle -e ':completion:*' matcher-list \
} >     'zstyle -a "word-${CURRENT}$LOOKUP" "$STYLE" reply'
} > 
} > The example names LOOKUP and STYLE are probably not the best choices.

Thinking about this further, there's no reason for the style to be in
a parameter; it's not a pattern, so by definition it must be the same
as in the previous link in the chain (e.g., must be matcher-list above).
Only the lookup pattern is unknown during the "zstye -e" evaluation.

} How about simply adding an option for chained styles [...]
} Admittedly, it'd be slightly less flexible.

Trouble with this is that the ":"-separated context bits are not a
feature of zstyle, they're a feature of the chosen use of zstyle in
compsys.  To add a chaining option we'd have to standardize on a
syntax for gluing sub-patterns together, which zstyle would know
about internally.  That seems a bad idea.

However, I came up with a solution to the "unknown lookup" problem
as well -- compsys always has extendedglob set, so:

    zstyle -e '(#b)(:completion:*)' matcher-list \
        'zstyle -a "word-$CURRENT$match" matcher-list reply'

A bit of a glitch with this is that zstyle does not save and restore
$match et al. around its pattern lookups, but that's easily fixable
because zregexparse already provides the necessary machinery right
there in zutils.c where zstyle is also defined.

Re: disable substring match on command name

[Bart Schaefer]

On Mar 8,  9:37pm, Bart Schaefer wrote:
}
}     zstyle -e '(#b)(:completion:*)' matcher-list \
}         'zstyle -a "word-$CURRENT$match" matcher-list reply'

Turns out there are two other minor gotchas with this:

(1) The pattern is compiled at the time the style is defined, so you
    must have extendedglob set for this to work; it's not sufficient
    that compsys has it set at the time of lookup.

(2) However, the zstyles are stored by the literal pattern string,
    so if you accidentally define one like this with extendedglob
    NOT set, you have to explicitly delete it with 'zstyle -d' and
    then re-create it; it does not work to simply execute exactly
    the same zstyle command again after toggling extendedglob.

I'm surprised the latter hasn't mysteriously bitten someone else in
a different situation, but I guess zstyles aren't something that one
frobs at the command line very often.