Re: [RFC] Add xfail tests for || form of completion matchers

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Marlon Richert wrote on Tue, Oct 12, 2021 at 15:08:46 +0300:
> On Mon, Oct 11, 2021 at 5:34 PM Marlon Richert <marlon.richert@xxxxxxxxx> wrote:
> >
> > The tests show how :||= matchers should behave in order to provide
> > completion features that cannot be implemented with :|= matchers.

Would this be backwards compatible?

> > This is a follow-up to users/27228.
> 
> I've now added an accompanying documentation update to the patch.

Thanks.  I have never found that section easy to follow.

Could you confirm that the text which the docs patch deletes or changes
was all confirmed correct (even if perhaps unclear)?  I'm concerned
about us possibly changing dense, accurate docs into clear, less-accurate
docs.

Case in point: The incumbent docs say that the coanchor is matched only
against the trial completion, but the new docs say something else.  If
that's an intentional change, it needs to be called out explicitly in
the log message.

Haven't looked for other differences.

In the man page rendering on my system, itemiz()'s bullet is vertically
aligned with the parent item()'s text.

Cheers,

Daniel

> From 3ec2fceced1f327eb2ac7484772bd1d3756bf8d2 Mon Sep 17 00:00:00 2001
> From: Marlon Richert <marlon.richert@xxxxxxxxx>
> Date: Tue, 12 Oct 2021 15:02:31 +0300
> Subject: [PATCH] Add xfail tests for || form of completion matchers
> 
> The tests show how :||= matchers should behave in order to provide
> completion features that cannot be implemented with :|= matchers.
> ---
>  Doc/Zsh/compwid.yo     | 446 ++++++++++++++++++-----------------------
>  Test/Y02compmatch.ztst | 108 +++++++++-
>  2 files changed, 293 insertions(+), 261 deletions(-)
> 
> diff --git a/Doc/Zsh/compwid.yo b/Doc/Zsh/compwid.yo
> index 3e86d3b42..5dd2127df 100644
> --- a/Doc/Zsh/compwid.yo
> +++ b/Doc/Zsh/compwid.yo
> @@ -896,72 +896,210 @@ enditem()
>  texinode(Completion Matching Control)(Completion Widget Example)(Completion Condition Codes)(Completion Widgets)
>  sect(Completion Matching Control)
>  
> -It is possible by use of the
> -tt(-M) option of the tt(compadd) builtin command to specify how the
> -characters in the string to be completed (referred to here as the
> -command line) map onto the characters in the list of matches produced by
> -the completion code (referred to here as the trial completions). Note
> -that this is not used if the command line contains a glob pattern and
> -the tt(GLOB_COMPLETE) option is set or the tt(pattern_match) of the
> -tt(compstate) special association is set to a non-empty string.
> -
> -The var(match-spec) given as the argument to the tt(-M) option (see
> +By default, characters in the string to be completed (referred to here as the
> +command line) map only onto identical characters in the list of matches
> +produced by the completion code (referred to here as the trial completions) and
> +missing characters are inserted only at the cursor position, if the shell
> +option tt(COMPLETE_IN_WORD) is set, or at the end of the command line,
> +otherwise.  However, it is possible to modify this behavior by use of the
> +tt(-M) option of the tt(compadd) builtin command.  Note that this is not used
> +if the command line contains a glob pattern and the shell
> +optiontt(GLOB_COMPLETE) is set or the tt(pattern_match) of the tt(compstate)
> +special association is set to a non-empty string.
> +
> +The tt(-M) option (see
>  ifzman(`Completion Builtin Commands' above)\
> -ifnzman(noderef(Completion Builtin Commands))\
> -) consists of one or more matching descriptions separated by
> -whitespace.  Each description consists of a letter followed by a colon
> -and then the patterns describing which character sequences on the line match
> -which character sequences in the trial completion.  Any sequence of
> -characters not handled in this fashion must match exactly, as usual.
> -
> -The forms of var(match-spec) understood are as follows. In each case, the
> -form with an upper case initial character retains the string already
> -typed on the command line as the final result of completion, while with
> -a lower case initial character the string on the command line is changed
> -into the corresponding part of the trial completion.
> +ifnzman(noderef(Completion Builtin
> +Commands))\
> +) requires a var(match-spec) as it argument, consisting of one or more matching
> +descriptions separated by whitespace.  Each description consists of a letter,
> +followed by a colon, and then patterns describing which substrings on the
> +command line map onto which substrings in the trial completion.  Descriptions
> +are evaluated from left to right and are cumulative.  An earlier mapping can
> +thus potentially change the outcome of a later mapping.  Finally, any unmapped
> +substrings will be mapped using the default mapping of identical substrings.
> +
> +When using the completion system (see
> +ifzman(zmanref(zshcompsys))\
> +ifnzman(noderef(Completion System))\
> +), users can define match specifications that are to be used for specific
> +contexts by using the tt(matcher) and tt(matcher-list) styles.  The values for
> +the latter will be used everywhere.
> +
> +Each pattern in a var(match-spec) is either an empty string or consists of a
> +sequence of literal characters (which may be quoted with a backslash), question
> +marks, character classes, and correspondence classes (see next paragraph).
> +Ordinary shell patterns are not used.  Literal characters match only
> +themselves, question marks match any character, and character classes are
> +formed as for globbing and match any character in the given set.
> +
> +Correspondence classes are defined like character classes, but with two
> +differences: They are delimited by a pair of braces, and negated classes are
> +not allowed, so the characters tt(!) and tt(^) have no special meaning directly
> +after the opening brace.  They indicate that a range of characters on the line
> +match a range of characters in the trial completion, but (unlike ordinary
> +character classes) paired according to the corresponding position in the
> +sequence.  More than one pair of classes can occur, in which case the first
> +class before the tt(=) corresponds to the first after it, and so on.  If one
> +side has more such classes than the other side, the superfluous classes behave
> +like normal character classes.
> +
> +The standard `tt([:)var(name)tt(:])' forms described for standard shell
> +patterns (see 
> +ifnzman(noderef(Filename Generation))\
> +ifzman(the section
> +FILENAME GENERATION in zmanref(zshexpn))\
> +) may appear in correspondence classes as well as normal character classes.
> +The only special behaviour in correspondence classes is if the form on the left
> +and the form on the right are each one of tt([:upper:]), tt([:lower:]).  In
> +these cases the character in the word and the character on the line must be the
> +same up to a difference in case.  Although the matching system does not yet
> +handle multibyte characters, this is likely to be a future extension, at which
> +point this syntax will handle arbitrary alphabets; hence this form, rather than
> +the use of explicit ranges, is the recommended form.  In other cases
> +`tt([:)var(name)tt(:])' forms are allowed.  If the two forms on the left and
> +right are the same, the characters must match exactly.  In remaining cases, the
> +corresponding tests are applied to both characters, but they are not otherwise
> +constrained; any matching character in one set goes with any matching character
> +in the other set: this is equivalent to the behaviour of ordinary character
> +classes.
> +
> +The forms of var(match-spec) understood are listed below.  For each of these,
> +the form with an upper case initial character replaces mapped substrings in the
> +trial completions with their counterparts from the command line, whereas with a
> +lower case initial character, once a trial completion has been accepted,
> +matched substrings on the command line are replaced with their counterparts
> +from the accepted completion.
>  
>  startitem()
>  xitem(tt(m:)var(lpat)tt(=)var(tpat))
>  item(tt(M:)var(lpat)tt(=)var(tpat))(
> -Here, var(lpat) is a pattern that matches on the command line,
> -corresponding to var(tpat) which matches in the trial completion.
> +Let any substring matching var(lpat) be completed to any substring matching
> +var(tpat).
> +
> +Examples:
> +
> +tt(m:{[:lower:]}={[:upper:]}) lets any lower case character be completed to its
> +uppercase counterpart.
> +
> +tt(M:_=) inserts every underscore on the command line into each trial
> +completion, in the same relative position, determined by matching the
> +substrings around it.  Note that the definition of what is matching can be
> +modified by applying other matchers first.
> +
> +If these two matchers are combined to tt('m:{[:lower:]}={[:upper:]} M:_='),
> +then given a trial completion `tt(NO)', it lets `tt(_n_o_)' be completed to
> +`tt(_N_O_)', even though `tt(_N_O_)' itself is not present as a trial
> +completion.  tt(m:{[:lower:]}={[:upper:]}) is evaluated first and makes `tt(n)`
> +match `tt(N)' and `tt(o)` match `tt(O)', after which tt(M:_=) is then able to
> +insert underscores into the correct positions.
> +)
> +xitem(tt(l:)tt(|)var(lpat)tt(=)var(tpat))
> +xitem(tt(L:)tt(|)var(lpat)tt(=)var(tpat))
> +xitem(tt(r:)var(lpat)tt(|)tt(=)var(tpat))
> +item(tt(R:)var(lpat)tt(|)tt(=)var(tpat))(
> +Let any substring matching var(lpat) at the left (for tt(l:) and tt(L:)) or
> +right (for tt(r:) and tt(R:)) edge of the command line be completed to any
> +substring matching var(tpat) in the same position in the trial completion.
> +
> +With these matchers, the pattern var(tpat) may also be a star, `tt(*)'.  This
> +lets a matching command line substring be completed to any trial completion
> +substring in the same relative position.
> +
> +Examples:
> +
> +tt(L:|[nN][oO]=) makes it so that, if there is a single `tt(no)', `tt(nO)',
> +`tt(No)' or `tt(no)' at the left end of the command line, then it is added to
> +the left of each trial completion.
> +
> +tt(r:|=*) lets (the empty substring at) the right edge of the command line
> +string be completed to any number of characters at the edge of each trial
> +completion.
> +
> +If these two matchers are combined to tt('L:[nN][oO]= r:|=*'), then given a
> +trial completion `tt(foo)', it lets `tt(NOf)' be completed to `tt(NOfoo)'.
> +First, tt(L:[nN][oO]=) prefixes the trial completion with tt(NO), after which
> +tt(r:|=*) is able to match the command line to the trial completion and
> +complete the missing characters at the end.
>  )
> -xitem(tt(l:)var(lanchor)tt(|)var(lpat)tt(=)var(tpat))
> -xitem(tt(L:)var(lanchor)tt(|)var(lpat)tt(=)var(tpat))
> -xitem(tt(l:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
> -xitem(tt(L:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
>  xitem(tt(b:)var(lpat)tt(=)var(tpat))
> -item(tt(B:)var(lpat)tt(=)var(tpat))(
> -These letters are for patterns that are anchored by another pattern on
> -the left side. Matching for var(lpat) and var(tpat) is as for tt(m) and
> -tt(M), but the pattern var(lpat) matched on the command line must be
> -preceded by the pattern var(lanchor).  The var(lanchor) can be blank to
> -anchor the match to the start of the command line string; otherwise the
> -anchor can occur anywhere, but must match in both the command line and
> -trial completion strings.
> -
> -If no var(lpat) is given but a var(ranchor) is, this matches the gap
> -between substrings matched by var(lanchor) and var(ranchor). Unlike
> -var(lanchor), the var(ranchor) only needs to match the trial
> -completion string.
> -
> -The tt(b) and tt(B) forms are similar to tt(l) and tt(L) with an empty 
> -anchor, but need to match only the beginning of the word on the command line
> -or trial completion, respectively.
> -)
> -xitem(tt(r:)var(lpat)tt(|)var(ranchor)tt(=)var(tpat))
> -xitem(tt(R:)var(lpat)tt(|)var(ranchor)tt(=)var(tpat))
> -xitem(tt(r:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
> -xitem(tt(R:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
> +xitem(tt(B:)var(lpat)tt(=)var(tpat))
>  xitem(tt(e:)var(lpat)tt(=)var(tpat))
>  item(tt(E:)var(lpat)tt(=)var(tpat))(
> -As tt(l), tt(L), tt(b) and tt(B), with the difference that the command
> -line and trial completion patterns are anchored on the right side.
> -Here an empty var(ranchor) and the tt(e) and tt(E) forms force the
> -match to the end of the command line or trial completion string.
> -
> -In the form where var(lanchor) is given, the var(lanchor) only needs
> -to match the trial completion string.
> +Let all substrings matching var(lpat) at the beginning (for tt(b:) and tt(B:))
> +or end (for tt(e:) and tt(E:)) of the command line be completed to the same
> +number of substrings matching var(tpat) in each trial completion in the same
> +relative position.
> +
> +Example:
> +
> +tt(B:[nN][oO]=) adds all occurences of `tt(no)', `tt(nO)', `tt(No)' and
> +`tt(NO)' at the beginning of the command line to the beginning of each trial
> +completion.  If tt(r:|=*) is added to this, then given a trial completion
> +`tt(foo)', it lets `tt(noNOf)' be completed to `tt(noNOfoo)'.
> +)
> +xitem(tt(l:)var(anchor)tt(|)var(lpat)tt(=)var(tpat))
> +xitem(tt(L:)var(anchor)tt(|)var(lpat)tt(=)var(tpat))
> +xitem(tt(r:)var(lpat)tt(|)var(anchor)tt(=)var(tpat))
> +item(tt(R:)var(lpat)tt(|)var(anchor)tt(=)var(tpat))(
> +Let any command line substring, which is left/right-adjacent (respectively) to
> +a substring matching var(anchor) and which matches var(lpat), be completed to
> +any trial completion substring, which
> +startitemize()
> +itemiz(\
> +is adjacent to the same substring and which
> +)
> +itemiz(\
> +matches var(tpat), but which
> +)
> +itemiz(\
> +does not contain any substrings matching var(anchor).
> +)
> +enditemize()
> +
> +When a matcher includes at least one anchor (which also applies to the forms
> +with two anchors, below), the pattern var(tpat) may also be one or two stars,
> +`tt(*)' or `tt(**)'.  The first star can match any number of characters, within
> +the constraints outlined above, whereas a second star removes the last
> +constraint and can match substrings matching var(anchor).
> +
> +Example:
> +
> +tt(r:|.=*) lets each dot be completed to any substring that ends at the right
> +in a dot, but does not otherwise contain any dots, in the trial string.  Thus,
> +given a trial string `tt(comp.sources.unix)', `tt(..unix)' can be completed to
> +it, but `tt(.unix)' cannot, since the matcher will refuse to map any dots other
> +than the one matched by the var(anchor).
> +)
> +xitem(tt(l:)var(anchor)tt(||)var(coanchor)tt(=)var(tpat))
> +xitem(tt(L:)var(anchor)tt(||)var(coanchor)tt(=)var(tpat))
> +xitem(tt(r:)var(coanchor)tt(||)var(anchor)tt(=)var(tpat))
> +item(tt(R:)var(coanchor)tt(||)var(anchor)tt(=)var(tpat))(
> +Lets the empty string between each two adjacent command line substrings
> +matching var(anchor) and var(coanchor), in the order given, be completed to any
> +trial completion substring, which
> +startitemize()
> +itemiz(\
> +is adjacent to the same two substrings and which
> +)
> +itemiz(\
> +matches var(tpat), but which
> +)
> +itemiz(\
> +does not contain any substrings matching var(anchor).
> +)
> +enditemize()
> +
> +Note there is no restriction on substrings matching var(coanchor).
> +
> +Example:
> +
> +tt(r:?||[[:upper:]]=*) will complete `tt(fHoo)' to `tt(fooHoo)', but not
> +`tt(Hoo)' to `tt(fooHoo)', because there is no character to the left of `tt(H)'
> +on the command line˙.  Likewise, it will not complete `tt(lHIS)' to
> +`tt(likeTHIS)', because, other than the one substring it maps to var(anchor),
> +it cannot map any substring containing uppercase letters in the trial
> +completion.
>  )
>  item(tt(x:))(
>  This form is used to mark the end of matching specifications:
> @@ -972,200 +1110,6 @@ function to override another.
>  )
>  enditem()
>  
> -Each var(lpat), var(tpat) or var(anchor) is either an empty string or
> -consists of a sequence of literal characters (which may be quoted with a
> -backslash), question marks, character classes, and correspondence
> -classes; ordinary shell patterns are not used.  Literal characters match
> -only themselves, question marks match any character, and character
> -classes are formed as for globbing and match any character in the given
> -set.
> -
> -Correspondence classes are defined like character classes, but with two
> -differences: they are delimited by a pair of braces, and negated classes
> -are not allowed, so the characters tt(!) and tt(^) have no special
> -meaning directly after the opening brace.  They indicate that a range of
> -characters on the line match a range of characters in the trial
> -completion, but (unlike ordinary character classes) paired according to
> -the corresponding position in the sequence.  For example, to make any
> -ASCII lower case letter on the line match the corresponding upper case
> -letter in the trial completion, you can use `tt(m:{a-z}={A-Z})'
> -(however, see below for the recommended form for this).  More
> -than one pair of classes can occur, in which case the first class before
> -the tt(=) corresponds to the first after it, and so on.  If one side has
> -more such classes than the other side, the superfluous classes behave
> -like normal character classes.  In anchor patterns correspondence classes
> -also behave like normal character classes.
> -
> -The standard `tt([:)var(name)tt(:])' forms described for standard shell
> -patterns (see
> -ifnzman(noderef(Filename Generation))\
> -ifzman(the section FILENAME GENERATION in zmanref(zshexpn)))
> -may appear in correspondence classes as well as normal character
> -classes.  The only special behaviour in correspondence classes is if
> -the form on the left and the form on the right are each one of
> -tt([:upper:]), tt([:lower:]).  In these cases the
> -character in the word and the character on the line must be the same up
> -to a difference in case.  Hence to make any lower case character on the
> -line match the corresponding upper case character in the trial
> -completion you can use `tt(m:{[:lower:]}={[:upper:]})'.  Although the
> -matching system does not yet handle multibyte characters, this is likely
> -to be a future extension, at which point this syntax will handle
> -arbitrary alphabets; hence this form, rather than the use of explicit
> -ranges, is the recommended form.  In other cases
> -`tt([:)var(name)tt(:])' forms are allowed.  If the two forms on the left
> -and right are the same, the characters must match exactly.  In remaining
> -cases, the corresponding tests are applied to both characters, but they
> -are not otherwise constrained; any matching character in one set goes
> -with any matching character in the other set:  this is equivalent to the
> -behaviour of ordinary character classes.
> -
> -The pattern var(tpat) may also be one or two stars, `tt(*)' or
> -`tt(**)'. This means that the pattern on the command line can match
> -any number of characters in the trial completion. In this case the
> -pattern must be anchored (on either side); in the case of a single
> -star, the var(anchor) then determines how much of the trial completion
> -is to be included DASH()- only the characters up to the next appearance of
> -the anchor will be matched. With two stars, substrings matched by
> -the anchor can be matched, too. In the forms that include two
> -anchors, `tt(*)' can match characters from the additional anchor
> -DASH()- var(lanchor) with tt(r) or var(ranchor) with tt(l).
> -
> -Examples:
> -
> -The keys of the tt(options) association defined by the tt(parameter)
> -module are the option names in all-lower-case form, without
> -underscores, and without the optional tt(no) at the beginning even
> -though the builtins tt(setopt) and tt(unsetopt) understand option names
> -with upper case letters, underscores, and the optional tt(no).  The
> -following alters the matching rules so that the prefix tt(no) and any
> -underscore are ignored when trying to match the trial completions
> -generated and upper case letters on the line match the corresponding
> -lower case letters in the words:
> -
> -example(compadd -M 'L:|[nN][oO]= M:_= M:{[:upper:]}={[:lower:]}' - \ 
> -  ${(k)options} )
> -
> -The first part says that the pattern `tt([nN][oO])' at the beginning
> -(the empty anchor before the pipe symbol) of the string on the
> -line matches the empty string in the list of words generated by
> -completion, so it will be ignored if present. The second part does the
> -same for an underscore anywhere in the command line string, and the
> -third part uses correspondence classes so that any
> -upper case letter on the line matches the corresponding lower case
> -letter in the word. The use of the upper case forms of the
> -specification characters (tt(L) and tt(M)) guarantees that what has
> -already been typed on the command line (in particular the prefix
> -tt(no)) will not be deleted.
> -
> -Note that the use of tt(L) in the first part means that it matches
> -only when at the beginning of both the command line string and the
> -trial completion. I.e., the string `tt(_NO_f)' would not be
> -completed to `tt(_NO_foo)', nor would `tt(NONO_f)' be completed to
> -`tt(NONO_foo)' because of the leading underscore or the second
> -`tt(NO)' on the line which makes the pattern fail even though they are 
> -otherwise ignored. To fix this, one would use `tt(B:[nN][oO]=)'
> -instead of the first part. As described above, this matches at the
> -beginning of the trial completion, independent of other characters or
> -substrings at the beginning of the command line word which are ignored
> -by the same or other var(match-spec)s.
> -
> -The second example makes completion case insensitive.  This is just
> -the same as in the option example, except here we wish to retain the
> -characters in the list of completions:
> -
> -example(compadd -M 'm:{[:lower:]}={[:upper:]}' ... )
> -
> -This makes lower case letters match their upper case counterparts.
> -To make upper case letters match the lower case forms as well:
> -
> -example(compadd -M 'm:{[:lower:][:upper:]}={[:upper:][:lower:]}' ... )
> -
> -A nice example for the use of tt(*) patterns is partial word
> -completion. Sometimes you would like to make strings like `tt(c.s.u)'
> -complete to strings like `tt(comp.source.unix)', i.e. the word on the
> -command line consists of multiple parts, separated by a dot in this
> -example, where each part should be completed separately DASH()- note,
> -however, that the case where each part of the word, i.e. `tt(comp)',
> -`tt(source)' and `tt(unix)' in this example, is to be completed from
> -separate sets of matches
> -is a different problem to be solved by the implementation of the
> -completion widget.  The example can be handled by:
> -
> -example(compadd -M 'r:|.=* r:|=*' \ 
> -  - comp.sources.unix comp.sources.misc ...)
> -
> -The first specification says that var(lpat) is the empty string, while
> -var(anchor) is a dot; var(tpat) is tt(*), so this can match anything
> -except for the `tt(.)' from the anchor in
> -the trial completion word.  So in `tt(c.s.u)', the matcher sees `tt(c)',
> -followed by the empty string, followed by the anchor `tt(.)', and
> -likewise for the second dot, and replaces the empty strings before the
> -anchors, giving `tt(c)[tt(omp)]tt(.s)[tt(ources)]tt(.u)[tt(nix)]', where
> -the last part of the completion is just as normal.
> -
> -With the pattern shown above, the string `tt(c.u)' could not be
> -completed to `tt(comp.sources.unix)' because the single star means
> -that no dot (matched by the anchor) can be skipped. By using two stars 
> -as in `tt(r:|.=**)', however, `tt(c.u)' could be completed to
> -`tt(comp.sources.unix)'. This also shows that in some cases,
> -especially if the anchor is a real pattern, like a character class,
> -the form with two stars may result in more matches than one would like.
> -
> -The second specification is needed to make this work when the cursor is
> -in the middle of the string on the command line and the option
> -tt(COMPLETE_IN_WORD) is set. In this case the completion code would
> -normally try to match trial completions that end with the string as
> -typed so far, i.e. it will only insert new characters at the cursor
> -position rather than at the end.  However in our example we would like
> -the code to recognise matches which contain extra characters after the
> -string on the line (the `tt(nix)' in the example).  Hence we say that the
> -empty string at the end of the string on the line matches any characters
> -at the end of the trial completion.
> -
> -More generally, the specification
> -
> -example(compadd -M 'r:|[.,_-]=* r:|=*' ... )
> -
> -allows one to complete words with abbreviations before any of the
> -characters in the square brackets.  For example, to
> -complete tt(veryverylongfile.c) rather than tt(veryverylongheader.h)
> -with the above in effect, you can just type tt(very.c) before attempting
> -completion.
> -
> -The specifications with both a left and a right anchor are useful to
> -complete partial words whose parts are not separated by some
> -special character. For example, in some places strings have to be
> -completed that are formed `tt(LikeThis)' (i.e. the separate parts are
> -determined by a leading upper case letter) or maybe one has to
> -complete strings with trailing numbers. Here one could use the simple
> -form with only one anchor as in:
> -
> -example(compadd -M 'r:|[[:upper:]0-9]=* r:|=*' LikeTHIS FooHoo 5foo123 5bar234)
> -
> -But with this, the string `tt(H)' would neither complete to `tt(FooHoo)'
> -nor to `tt(LikeTHIS)' because in each case there is an upper case
> -letter before the `tt(H)' and that is matched by the anchor. Likewise, 
> -a `tt(2)' would not be completed. In both cases this could be changed
> -by using `tt(r:|[[:upper:]0-9]=**)', but then `tt(H)' completes to both
> -`tt(LikeTHIS)' and `tt(FooHoo)' and a `tt(2)' matches the other
> -strings because characters can be inserted before every upper case
> -letter and digit. To avoid this one would use:
> -
> -example(compadd -M 'r:[^[:upper:]0-9]||[[:upper:]0-9]=** r:|=*' \ 
> -    LikeTHIS FooHoo foo123 bar234)
> -
> -By using these two anchors, a `tt(H)' matches only upper case `tt(H)'s that 
> -are immediately preceded by something matching the left anchor
> -`tt([^[:upper:]0-9])'. The effect is, of course, that `tt(H)' matches only
> -the string `tt(FooHoo)', a `tt(2)' matches only `tt(bar234)' and so on.
> -
> -When using the completion system (see
> -ifzman(zmanref(zshcompsys))\
> -ifnzman(noderef(Completion System))\
> -), users can define match specifications that are to be used for
> -specific contexts by using the tt(matcher) and tt(matcher-list)
> -styles. The values for the latter will be used everywhere.
> -
>  texinode(Completion Widget Example)()(Completion Matching Control)(Completion Widgets)
>  sect(Completion Widget Example)
>  cindex(completion widgets, example)
> diff --git a/Test/Y02compmatch.ztst b/Test/Y02compmatch.ztst
> index 621707482..ee7e422c1 100644
> --- a/Test/Y02compmatch.ztst
> +++ b/Test/Y02compmatch.ztst
> @@ -378,15 +378,26 @@