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

[Marlon Richert <marlon.richert@xxxxxxxxx>]

Thanks for your comments. :)

Attached is a new version of the patch, which should address most of
your points and also corrects some false assumptions I had about the
matching logic. Below are my replies to points not addressed by the
patch.


On Wed, Oct 13, 2021 at 7:57 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> For example, this part is misleading:
>
> > > +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
> [...]
> > > +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,
>
> It's at the end of the current word, not the end of the command line.
> The old wording nearly always says "string on the command line" which
> is only somewhat better; if it's going to be completely rewritten to
> drop "string on the", the phrase "command line" should become more
> precise.  "Incomplete word" perhaps?

On Thu, Oct 14, 2021 at 11:43 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> Is "trial completions" the best term we can come up with? Where it
> occurs in singular form it isn't obvious that it doesn't refer to what
> is on the command-line. I tend use "candidate matches". With the term
> "matches" for those that remain following matching. Or does anyone have
> other ideas?

I iterations over several permutations of terms in the docs and found
that this one seems to work best:

"When the user invokes completion, the _current word_ on the command
line is used to generate a _match pattern_ defining which
_completions_ are considered _matches._"

This also matches the use of these terms in the majority of the
manual. Where it doesn't match in compwid.yo, I've changed the text so
that it does.


On Thu, Oct 14, 2021 at 11:43 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> "completions" is already rather overloaded because it is
> also used for completion definitions for commands.

I used "completions" anyway, because it feels like the most natural
and concise word to use for this purpose. It doesn't appear to cause
any ambiguities in the text.


On Fri, Oct 22, 2021 at 4:02 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> > --- a/Test/Y02compmatch.ztst
> > +++ b/Test/Y02compmatch.ztst
>
> > - comptest $'tst c...pag\t'
> > -0:Documentation example using input c...pag\t
> > + comptest $'tst ...pag\t'
> > +0:Documentation example using input ...pag
>
> It is good to have tests matching exactly the examples in the documentation but
> in some cases there could be value in preserving the essence of the old test
> too. To get good test coverage, we want empty and partial components in both
> the middle and beginning of the command line to be tested.

I'm not sure what these tests should look like. So, I didn't add them.


On Fri, Oct 22, 2021 at 4:02 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> > + example5b_matcher='r:[^.,_-]||[.,_-]=* r:|=*'
> > + test_code $example5b_matcher example5_list
> > + comptest $'tst  .c\t^[bv\t.h\t^[bv'
> > +0f:Documentation example using input .c but with double anchor
>
> The second tab doesn't really test the matcher because the cursor is located
> where characters need to be added.

On Thu, Oct 14, 2021 at 11:43 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> I'm fairly sure that if complete_in_word is unset, missing characters
> are still allowed at the cursor position.

No, it does not appear to work like that in vanilla zsh:

% PS1='%# ' zsh -f
% autoload compinit; compinit
% _tst() { compadd veryverylongfile.c }
% tst v.c^B^B\t

The word 'v.c' in this example will not get completed, no matter where
you put the cursor.

From 94bab5e505aecd4b437187ab938c3c08948233db Mon Sep 17 00:00:00 2001
From: Marlon Richert <marlon.richert@xxxxxxxxx>
Date: Mon, 25 Oct 2021 21:33:29 +0300
Subject: [PATCH] Define correct behavior of || completion matchers

* Add xfail tests to show how :||= matchers should behave in order to
  provide completion features that cannot be implemented with :|=
  matchers.
* Update compwid.yo to further describe the correct behavior.
* Update compwid.yo to use completion terminology more consistently.
---
 Doc/Zsh/compwid.yo     | 671 +++++++++++++++++++++--------------------
 Test/Y02compmatch.ztst | 126 ++++++--
 2 files changed, 450 insertions(+), 347 deletions(-)

diff --git a/Doc/Zsh/compwid.yo b/Doc/Zsh/compwid.yo
index 3e86d3b42..1a606f19c 100644
--- a/Doc/Zsh/compwid.yo
+++ b/Doc/Zsh/compwid.yo
@@ -39,7 +39,7 @@ using the tt(bindkey) builtin command defined in the tt(zsh/zle) module
 ifzman(see zmanref(zshzle))\
 ifnzman(noderef(Zsh Line Editor))\
 ), typing that key will call the shell function `tt(completer)'. This
-function is responsible for generating the possible matches using the
+function is responsible for generating completion matches using the
 builtins described below.  As with other ZLE widgets, the function is
 called with its standard input closed.
 
@@ -213,7 +213,7 @@ The string of an exact match if one was found, otherwise unset.
 )
 vindex(ignored, compstate)
 item(tt(ignored))(
-The number of words that were ignored because they matched one of the
+The number of completions that were ignored because they matched one of the
 patterns given with the tt(-F) option to the tt(compadd) builtin
 command.
 )
@@ -309,8 +309,7 @@ will be used in the same way as the value of tt(LISTMAX).
 )
 vindex(nmatches, compstate)
 item(tt(nmatches))(
-The number of matches generated and accepted by the completion code so
-far.
+The number of matches added by the completion code so far.
 )
 vindex(old_insert, compstate)
 item(tt(old_insert))(
@@ -346,7 +345,8 @@ value of a parameter assignment.
 vindex(pattern_insert, compstate)
 item(tt(pattern_insert))(
 Normally this is set to tt(menu), which specifies that menu completion will
-be used whenever a set of matches was generated using pattern matching.  If
+be used whenever a set of matches was generated using 
+tt(pattern_match) (see below).  If
 it is set to any other non-empty string by the user and menu completion is
 not selected by other option settings, the code will instead insert any
 common prefix for the generated matches as with normal completion.
@@ -362,7 +362,7 @@ command line will be treated as patterns; if it is `tt(*)', then
 additionally a wildcard `tt(*)' is assumed at the cursor position; if
 it is empty or unset, metacharacters will be treated literally.
 
-Note that the matcher specifications given to the tt(compadd) builtin
+Note that the match specifications given to the tt(compadd) builtin
 command are not used if this is set to a non-empty string.
 )
 vindex(quote, compstate)
@@ -456,17 +456,16 @@ xitem(SPACES()[tt(-V) var(group-name) ] [ tt(-o) [ var(order) ] ])
 xitem(SPACES()[tt(-r) var(remove-chars) ] [ tt(-R) var(remove-func) ])
 xitem(SPACES()[tt(-D) var(array) ] [ tt(-O) var(array) ] [ tt(-A) var(array) ])
 xitem(SPACES()[tt(-E) var(number) ])
-item(SPACES()[tt(-M) var(match-spec) ] [ tt(-)tt(-) ] [ var(words) ... ])(
+item(SPACES()[tt(-M) var(match-spec) ] [ tt(-)tt(-) ] [ var(completions) ... ])(
 
 This builtin command can be used to add matches directly and control
 all the information the completion code stores with each possible
-match. The return status is zero if at least one match was added and
+completion. The return status is zero if at least one match was added and
 non-zero if no matches were added.
 
-The completion code breaks the string to complete into seven fields in
-the order: 
+The completion code breaks each match into seven fields in the order:
 
-indent(var(<ipre><apre><hpre><word><hsuf><asuf><isuf>))
+indent(var(<ipre><apre><hpre><body><hsuf><asuf><isuf>))
 
 The first field
 is an ignored prefix taken from the command line, the contents of the
@@ -474,12 +473,12 @@ tt(IPREFIX) parameter plus the string given with the tt(-i)
 option. With the tt(-U) option, only the string from the tt(-i)
 option is used. The field var(<apre>) is an optional prefix string
 given with the tt(-P) option.  The var(<hpre>) field is a string
-that is considered part of the match but that should not be shown when 
+that is considered part of the match but that should not be shown when
 listing completions, given with the tt(-p) option; for example,
 functions that do filename generation might specify
-a common path prefix this way.  var(<word>) is the part of the match that
-should appear in the list of completions, i.e. one of the var(words) given
-at the end of the tt(compadd) command line. The suffixes var(<hsuf>),
+a common path prefix this way.  var(<body>) is the part of the match that
+should appear in the list of matches shown to the user.  
+The suffixes var(<hsuf>),
 var(<asuf>) and var(<isuf>) correspond to the prefixes var(<hpre>),
 var(<apre>) and var(<ipre>) and are given by the options tt(-s), tt(-S) and
 tt(-I), respectively.
@@ -488,52 +487,52 @@ The supported flags are:
 
 startitem()
 item(tt(-P) var(prefix))(
-This gives a string to be inserted before the given var(words).  The
+This gives a string to be inserted before each match.  The
 string given is not considered as part of the match and any shell
 metacharacters in it will not be quoted when the string is inserted.
 )
 item(tt(-S) var(suffix))(
-Like tt(-P), but gives a string to be inserted after the match.
+Like tt(-P), but gives a string to be inserted after each match.
 )
 item(tt(-p) var(hidden-prefix))(
-This gives a string that should be inserted into the command line before the
+This gives a string that should be inserted before each
 match but that should not appear in the list of matches. Unless the
 tt(-U) option is given, this string must be matched as part of the string
 on the command line.
 )
 item(tt(-s) var(hidden-suffix))(
-Like `tt(-p)', but gives a string to insert after the match.
+Like `tt(-p)', but gives a string to insert after each match.
 )
 item(tt(-i) var(ignored-prefix))(
-This gives a string to insert into the command line just before any
+This gives a string to insert just before any
 string given with the `tt(-P)' option.  Without `tt(-P)' the string is
-inserted before the string given with `tt(-p)' or directly before the
+inserted before the string given with `tt(-p)' or directly before each
 match.
 )
 item(tt(-I) var(ignored-suffix))(
 Like tt(-i), but gives an ignored suffix.
 )
 item(tt(-a))(
-With this flag the var(words) are taken as names of arrays and the
-possible matches are their values.  If only some elements of the
-arrays are needed, the var(words) may also contain subscripts, as in
+With this flag the var(completions) are taken as names of arrays and the
+actual completions are their values.  If only some elements of the
+arrays are needed, the var(completions) may also contain subscripts, as in
 `tt(foo[2,-1])'.
 )
 item(tt(-k))(
-With this flag the var(words) are taken as names of associative arrays
-and the possible matches are their keys.  As for tt(-a), the
+With this flag the var(completions) are taken as names of associative arrays
+and the actual completions are their keys.  As for tt(-a), the
 var(words) may also contain subscripts, as in `tt(foo[(R)*bar*])'.
 )
 item(tt(-d) var(array))(
-This adds per-match display strings. The var(array) should contain one 
-element per var(word) given. The completion code will then display the 
-first element instead of the first var(word), and so on. The
+This adds per-completion display strings. The var(array) should contain one
+element per var(completion) given. The completion code will then display the
+first element instead of the first var(completion), and so on. The
 var(array) may be given as the name of an array parameter or directly
 as a space-separated list of words in parentheses.
 
-If there are fewer display strings than var(words), the leftover
-var(words) will be displayed unchanged and if there are more display
-strings than var(words), the leftover display strings will be silently
+If there are fewer display strings than var(completions), the leftover
+var(completions) will be displayed unchanged and if there are more display
+strings than var(completions), the leftover display strings will be silently
 ignored.
 )
 item(tt(-l))(
@@ -556,7 +555,8 @@ by the tt(-d) option). This is the default if `tt(-o)' is specified but
 the var(order) argument is omitted.
 )
 item(tt(nosort))(
-This specifies that the matches are pre-sorted and their order should be
+This specifies that the var(completions) 
+are pre-sorted and their order should be
 preserved.  This value only makes sense alone and cannot be combined with any
 others.
 )
@@ -570,7 +570,7 @@ Arrange the matches backwards by reversing the sort ordering.
 enditem()
 )
 item(tt(-J) var(group-name))(
-Gives the name of the group of matches the words should be stored in.
+Gives the name of the group that the matches should be stored in.
 )
 item(tt(-V) var(group-name))(
 Like tt(-J) but naming an unsorted group. This option is identical to
@@ -616,13 +616,13 @@ produce unexpected results. If arbitrary text is to be passed in a
 description, it can be escaped using e.g. tt(${my_str//\%/%%}).
 )
 item(tt(-x) var(message))(
-Like tt(-X), but the var(message) will be printed even if there are no 
+Like tt(-X), but the var(message) will be printed even if there are no
 matches in the group.
 )
 item(tt(-q))(
-The suffix given with tt(-S) will be automatically removed if 
+The suffix given with tt(-S) will be automatically removed if
 the next character typed is a blank or does not insert anything, or if
-the suffix consists of only one character and the next character typed 
+the suffix consists of only one character and the next character typed
 is the same character.
 )
 item(tt(-r) var(remove-chars))(
@@ -644,8 +644,8 @@ automatically added space will be removed when one of the characters in the
 list is typed.
 )
 item(tt(-R) var(remove-func))(
-This is another form of the tt(-r) option. When a suffix 
-has been inserted and the completion accepted, the function
+This is another form of the tt(-r) option. When a match 
+has been accepted and a suffix has been inserted, the function
 var(remove-func) will be called after the next character typed.  It is
 passed the length of the suffix as an argument and can use the special
 parameters available in ordinary (non-completion) zle widgets (see
@@ -654,7 +654,7 @@ ifnzman(noderef(Zsh Line Editor))\
 ) to analyse and modify the command line.
 )
 item(tt(-f))(
-If this flag is given, all of the matches built from var(words) are
+If this flag is given, all of the matches built from the var(completions) are
 marked as being the names of files.  They are not required to be actual
 filenames, but if they are, and the option tt(LIST_TYPES) is set, the
 characters describing the types of the files in the completion lists will
@@ -668,15 +668,14 @@ the tt(AUTO_PARAM_SLASH) and tt(AUTO_PARAM_KEYS) options be used for
 the matches.
 )
 item(tt(-W) var(file-prefix))(
-This string is a pathname that will be
-prepended to each of the matches formed by the given var(words) together 
+This string is a pathname that will be prepended to each match together
 with any prefix specified by the tt(-p) option to form a complete filename
 for testing.  Hence it is only useful if combined with the tt(-f) flag, as
 the tests will not otherwise be performed.
 )
 item(tt(-F) var(array))(
-Specifies an array containing patterns. Words matching one of these
-patterns are ignored, i.e. not considered to be possible matches.
+Specifies an array containing patterns.  var(completions) that match one of
+these patterns are ignored, that is, not considered to be matches.
 
 The var(array) may be the name of an array parameter or a list of
 literal patterns enclosed in parentheses and quoted, as in `tt(-F "(*?.o
@@ -684,8 +683,8 @@ literal patterns enclosed in parentheses and quoted, as in `tt(-F "(*?.o
 taken as the patterns.
 )
 item(tt(-Q))(
-This flag instructs the completion 
-code not to quote any metacharacters in the words when inserting them
+This flag instructs the completion
+code not to quote any metacharacters in the matches when inserting them
 into the command line.
 )
 item(tt(-M) var(match-spec))(
@@ -696,47 +695,48 @@ between them to form the specification string to use.
 Note that they will only be used if the tt(-U) option is not given.
 )
 item(tt(-n))(
-Specifies that the words added are to be used as possible
-matches, but are not to appear in the completion listing.
+Specifies that matching var(completions) are to be added to the set of
+matches, but are not to be listed to the user.
 )
 item(tt(-U))(
-If this flag is given, all words given will be accepted and no matching
+If this flag is given, all var(completions) are added
+to the set of matches and no matching
 will be done by the completion code. Normally this is used in
 functions that do the matching themselves.
 )
 item(tt(-O) var(array))(
-If this option is given, the var(words) are em(not) added to the set of
-possible completions.  Instead, matching is done as usual and all of the
-var(words) given as arguments that match the string on the command line
+If this option is given, the var(completions) are em(not) added to the set of
+matches.  Instead, matching is done as usual and all of the
+var(completions) that match 
 will be stored in the array parameter whose name is given as var(array).
 )
 item(tt(-A) var(array))(
-As the tt(-O) option, except that instead of those of the var(words) which
+As the tt(-O) option, except that instead of those of the var(completions)
+which
 match being stored in var(array), the strings generated internally by the
-completion code are stored. For example,
-with a matching specification of `tt(-M "L:|no=")', the string `tt(nof)'
-on the command line and the string `tt(foo)' as one of the var(words), this
+completion code are stored.  For example,
+with a match specification of `tt(-M "L:|no=")', a current word of `tt(nof)'
+and var(completions) of `tt(foo)', this
 option stores the string `tt(nofoo)' in the array, whereas the tt(-O)
 option stores the `tt(foo)' originally given.
 )
 item(tt(-D) var(array))(
-As with tt(-O), the var(words) are not added to the set of possible
-completions.  Instead, the completion code tests whether each var(word) 
-in turn matches what is on the line.  If the var(n)th var(word) does not
+As with tt(-O), the var(completions) are not added to the set of matches.
+Instead, whenever the var(n)th var(completion) does not
 match, the var(n)th element of the var(array) is removed.  Elements
-for which the corresponding var(word) is matched are retained.
+for which the corresponding var(completion) matches are retained.
 )
 item(tt(-C))(
 This option adds a special match which expands to all other matches
 when inserted into the line, even those that are added after this
 option is used.  Together with the tt(-d) option it is possible to
-specify a string that should be displayed in the list for this special 
-match.  If no string is given, it will be shown as a string containing 
-the strings that would be inserted for the other matches, truncated to 
+specify a string that should be displayed in the list for this special
+match.  If no string is given, it will be shown as a string containing
+the strings that would be inserted for the other matches, truncated to
 the width of the screen.
 )
 item(tt(-E) var(number))(
-This option adds var(number) empty matches after the var(words) have
+This option adds var(number) empty matches after matching var(completions) have
 been added.  An empty match takes up space in completion listings but
 will never be inserted in the line and can't be selected with menu
 completion or menu selection.  This makes empty matches only useful to
@@ -751,7 +751,7 @@ added.
 xitem(tt(-))
 item(tt(-)tt(-))(
 This flag ends the list of flags and options. All arguments after it
-will be taken as the words to use as matches even if they begin with
+will be taken as the var(completions) even if they begin with
 hyphens.
 )
 enditem()
@@ -788,7 +788,7 @@ Without the optional var(number), the longest match is taken, but
 if var(number) is given, anything up to the var(number)th match is
 moved.  If the var(number) is negative, the var(number)th longest
 match is moved. For example, if tt(PREFIX) contains the string
-`tt(a=b=c)', then tt(compset -P '*\=') will move the string `tt(a=b=)' 
+`tt(a=b=c)', then tt(compset -P '*\=') will move the string `tt(a=b=)'
 into the tt(IPREFIX) parameter, but tt(compset -P 1 '*\=') will move only
 the string `tt(a=)'.
 )
@@ -801,7 +801,7 @@ As tt(-P), but match the last portion of tt(SUFFIX) and transfer the
 matched portion to the front of the value of tt(ISUFFIX).
 )
 item(tt(-n) var(begin) [ var(end) ])(
-If the current word position as specified by the parameter tt(CURRENT) 
+If the current word position as specified by the parameter tt(CURRENT)
 is greater than or equal to var(begin), anything up to the
 var(begin)th word is removed from the tt(words) array and the value
 of the parameter tt(CURRENT) is decremented by var(begin).
@@ -824,7 +824,7 @@ point to the same word in the changed array.
 If the optional pattern var(end-pat) is also given, and there is an
 element in the tt(words) array matching this pattern, the parameters
 are modified only if the index of this word is higher than the one
-given by the tt(CURRENT) parameter (so that the matching word has 
+given by the tt(CURRENT) parameter (so that the matching word has
 to be after the cursor). In this case, the words starting with the one
 matching tt(end-pat) are also removed from the tt(words)
 array. If tt(words) contains no word matching var(end-pat), the
@@ -833,7 +833,7 @@ testing and modification is performed as if it were not given.
 item(tt(-q))(
 The word
 currently being completed is split on spaces into separate words,
-respecting the usual shell quoting conventions.  The 
+respecting the usual shell quoting conventions.  The
 resulting words are stored in the tt(words) array, and tt(CURRENT),
 tt(PREFIX), tt(SUFFIX), tt(QIPREFIX), and tt(QISUFFIX) are modified to
 reflect the word part that is completed.
@@ -885,7 +885,7 @@ item(tt(-suffix) [ var(number) ] var(pattern))(
 true if the test for the tt(-S) option of tt(compset) would succeed.
 )
 item(tt(-after) var(beg-pat))(
-true if the test of the tt(-N) option with only the var(beg-pat) given 
+true if the test of the tt(-N) option with only the var(beg-pat) given
 would succeed.
 )
 item(tt(-between) var(beg-pat end-pat))(
@@ -896,275 +896,286 @@ 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.
+When the user invokes completion, the current em(word) on the command line
+(that is, the word the cursor is currently on) is used to generate a em(match
+pattern).  Only those em(completions) that match the pattern are offered to the
+user as em(matches). 
 
-The var(match-spec) given as the argument to the tt(-M) option (see
+The default match pattern is generated from the current word by either
+
+startitemize()
+itemiz(\
+appending a `tt(*)' (matching any number of characters in a completion)
+em(or,)\
+)
+itemiz(\
+if the shell option tt(COMPLETE_IN_WORD) is set, inserting a `tt(*)' at the
+cursor position.\
+)
+enditemize()
+
+This narrow pattern can be broadened selectively by passing a em(match
+specification) to the tt(compadd) builtin command through its 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.
+).  A match specification consists of one or more var(matchers) separated by
+whitespace.  Matchers in a match specification are applied one at a time, from
+left to right.  Once all matchers have been applied, completions are compared
+to the final match pattern and non-matching ones are discarded.
+
+startitemize()
+itemiz(\
+Note that the tt(-M) option is ignored if the current word contains a glob
+pattern and the shell option tt(GLOB_COMPLETE) is set or if the
+tt(pattern_match) key of the special associative array tt(compstate) is set to
+a non-empty value (see
+ifzman(`Completion Special Parameters' above)\
+ifnzman(noderef(Completion Special Parameters))\
+).\
+)
+itemiz(\
+Users of the \
+ifzman(completion system (see zmanref(zshcompsys))) \
+ifnzman(noderef(Completion System)) \
+should generally not use the tt(-M) option directly, but rather use the
+tt(matcher-list) and tt(matcher) styles (see the subsection em(Standard Styles)
+in
+ifzman(\
+the documentation for COMPLETION SYSTEM CONFIGURATION in zmanref(zshcompsys))\
+ifnzman(noderef(Completion System Configuration))\
+).\
+)
+enditemize()
+
+Each matcher consists of
+
+startitemize()
+itemiz(a case-sensitive letter)
+itemiz(a `tt(:)',)
+itemiz(one or more patterns separated by pipes (`tt(|)'),)
+itemiz(an equals sign (`tt(=)'), and)
+itemiz(another pattern.)
+enditemize()
+
+The patterns before the `tt(=)' are used to match substrings of the current
+word.  For each matched substring, the corresponding part of the match pattern
+is broadened with the pattern after the `tt(=)', by means of a logical tt(OR).
+
+Each pattern in a matcher cosists of either
+
+startitemize()
+itemiz(the empty string or)
+itemiz(a sequence of
+
+startitemize()
+itemiz(literal characters (which may be quoted with a `tt(\)'),)
+itemiz(question marks (`tt(?)'),)
+itemiz(\
+bracket expressions (`tt([...])'; see the subsection em(Glob Operators) in
+ifnzman(noderef(Filename Generation))\
+ifzman(the documentation for GLOB OPERATORS in zmanref(zshexpn))\
+), and/or\
+)
+itemiz(brace expressions (see below).)
+enditemize()
+)
+enditemize()
+
+Other shell patterns are not allowed.
+
+A brace expression, like a bracket expression, consists of a list of
+
+startitemize()
+itemiz(literal characters,)
+itemiz(ranges (`tt(0-9)'), and/or)
+itemiz(character classes (`tt([:)var(name)tt(:])').)
+enditemize()
+
+However, they differ from each other as follows:
+
+startitemize()
+itemiz(\
+A brace expression is delimited by a pair of braces (`tt({...})').\
+)
+itemiz(\
+Brace expressions do not support negations.  That is, an initial
+`tt(!)' or `tt(^)' has no special meaning and will be interpreted as a literal
+character.\
+)
+itemiz(\
+When a character in the current word matches the var(n)th pattern in a brace
+expression, the corresponding part of the match pattern is broadened only with
+the var(n)th pattern of the brace expression on the other side of the `tt(=)',
+if there is one; if there is no brace expression on the other side, then this
+pattern is the empty string.  However, if either brace expression has more
+elements than the other, then the excess entries are simply ignored.  When
+comparing indexes, each literal character or character class counts as one
+element, but each range is instead expanded to the full list of literal
+characters it represents.  Additionally, if on em(both) sides of the
+`tt(=)', the var(n)th pattern is `tt([:upper:])' or `tt([:lower:])', then these
+are expanded as ranges, too.\
+)
+enditemize()
+
+Note that, although the matching system does not yet handle multibyte
+characters, this is likely to be a future extension.  Hence, using
+`tt([:upper:])' and `tt([:lower:])' is recommended over
+`tt(A-Z)' and `tt(a-z)'.
+
+Below are the different forms of matchers supported.  Each em(uppercase) form
+behaves exactly like its lowercase counterpart, but adds an additional step
+em(after) the match pattern has filtered out non-matching completions:  Each of
+a match's substrings that was matched by a subpattern from an uppercase matcher
+is replaced with the corresponding substring of the current word.  However,
+patterns from em(lowercase) matchers have higher weight:  If a substring of the
+current word was matched by patterns from both a lowercase and an uppercase
+matcher, then the lowercase matcher's pattern wins and the corresponding part
+of the match is not modified.
+
+Unless indicated otherwise, each example listed assumes tt(COMPLETE_IN_WORD) to
+be unset (as it is by default).
 
 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.
-)
-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(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.
+xitem(tt(m:)var(word-pat)tt(=)var(match-pat))
+item(tt(M:)var(word-pat)tt(=)var(match-pat))(
+
+For each substring of the current word that matches var(word-pat), broaden the
+corresponding part of the match pattern to additionally match var(match-pat).
+
+startitem()
+item(Examples:)(
+
+tt(m:{[:lower:]}={[:upper:]}) lets any lower case character in the current word
+be completed to itself or its uppercase counterpart.  So, the completions
+`tt(foo)', `tt(FOO)' and `tt(Foo)' will are be considered matches for the word
+`tt(fo)'.
+
+tt(M:_=) inserts every underscore from the current word into each match, in the
+same relative position, determined by matching the substrings around it.  So,
+given a completion `tt(foo)', the word `tt(f_o)' will be completed to the match
+`tt(f_oo)', even though the latter was not present as a completion.
 )
-item(tt(x:))(
-This form is used to mark the end of matching specifications:
-subsequent specifications are ignored. In a single standalone list
-of specifications this has no use but where matching specifications
-are accumulated, such as from nested function calls, it can allow one
-function to override another.
+enditem()
+)
+xitem(tt(b:)var(word-pat)tt(=)var(match-pat))
+xitem(tt(B:)var(word-pat)tt(=)var(match-pat))
+xitem(tt(e:)var(word-pat)tt(=)var(match-pat))
+item(tt(E:)var(word-pat)tt(=)var(match-pat))(
+
+For each consecutive substring at the tt(b:)eginning or tt(e:)nd of the current
+word that matches var(word-pat), broaden the corresponding part of the match
+pattern to additionally match var(match-pat).
+
+startitem()
+item(Examples:)(
+
+`tt(b:-=+)' lets any number of minuses at the start of the current word be
+completed to a minus or a plus.
+
+`tt(B:0=)' adds all zeroes at the beginning of the current word to the
+beginning of each match.
 )
 enditem()
+)
+xitem(tt(l:)tt(|)var(word-pat)tt(=)var(match-pat))
+xitem(tt(L:)tt(|)var(word-pat)tt(=)var(match-pat))
+xitem(tt(R:)var(word-pat)tt(|)tt(=)var(match-pat))
+item(tt(r:)var(word-pat)tt(|)tt(=)var(match-pat))(
 
-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))\
+If there is a substring at the tt(l:)eft or tt(r:)ight edge of the current word
+that matches var(word-pat), then broaden the corresponding part of the match
+pattern to additionally match var(match-pat).
+
+For each tt(l:), tt(L:), tt(r:) and tt(R:) matcher (including the ones below),
+the pattern var(match-pat) may also be a `tt(*)'.  This matches any number of
+characters in a completion.
+
+startitem()
+item(Examples:)(
+
+`tt(r:|=*)' appends a `tt(*)' to the match pattern, even when
+tt(COMPLETE_IN_WORD) is set and the cursor is not at the end of the current
+word.
+
+If the current word starts with a minus, then `tt(L:|-=)' will prepend it to
+each match.
+)
+enditem()
+)
+xitem(tt(l:)var(anchor)tt(|)var(word-pat)tt(=)var(match-pat))
+xitem(tt(L:)var(anchor)tt(|)var(word-pat)tt(=)var(match-pat))
+xitem(tt(r:)var(word-pat)tt(|)var(anchor)tt(=)var(match-pat))
+item(tt(R:)var(word-pat)tt(|)var(anchor)tt(=)var(match-pat))(
+
+For each substring of the current word that matches var(word-pat) and has on
+its tt(l:)eft or tt(r:)ight another substring matching var(anchor), broaden the
+corresponding part of the match pattern to additionally match var(match-pat).
+
+Note that these matchers (and the ones below) modify only what is matched by
+var(word-pat); they do not change the matching behavior of what is matched by
+var(anchor) (or var(coanchor); see the matchers below).  Thus, unless its
+corresponding part of the match pattern has been modified, the anchor in the
+current word has to match literally in each completion, just like any other
+substring of the current word.
+
+If a matcher includes at least one anchor (which includes the matchers with two
+anchors, below), then var(match-pat) may also be `tt(*)' or `tt(**)'.  `tt(*)'
+can match any part of a completion that does not contain any substrings
+matching var(anchor), whereas a `tt(**)' can match any part of a completion,
+period.  (Note that this is different from the behavior of `tt(*)' in the
+anchorless forms of `tt(l:)' and `tt(r:)' and and also different from `tt(*)'
+and `tt(**)' in glob expressions.)
+
+startitem()
+item(Examples:)(
+
+`tt(r:|.=*)' makes the completion `tt(comp.sources.unix)' a match for the word
+`tt(..u)' DASH()- but em(not) for the word `tt(.u)'.
+
+Given a completion `tt(-)tt(-foo)', the matcher `tt(L:--|no-=)' will complete
+the word `tt(-)tt(-no-)' to the match `tt(-)tt(-no-foo)'.
+)
+enditem()
+)
+xitem(tt(l:)var(anchor)tt(||)var(coanchor)tt(=)var(match-pat))
+xitem(tt(L:)var(anchor)tt(||)var(coanchor)tt(=)var(match-pat))
+xitem(tt(r:)var(coanchor)tt(||)var(anchor)tt(=)var(match-pat))
+item(tt(R:)var(coanchor)tt(||)var(anchor)tt(=)var(match-pat))(
+
+For any two consecutive substrings of the current word that match var(anchor)
+and var(coanchor), in the order given, insert the pattern var(match-pat)
+between their corresponding parts in the match pattern.
+
+Note that, unlike var(anchor), the pattern var(coanchor) does not change what
+`tt(*)' can match.
+
+startitem()
+item(Examples:)(
+
+`tt(r:?||[[:upper:]]=*)' will complete the current word `tt(fB)' to
+`tt(fooBar)', but it will not complete it to `tt(fooHooBar)' (because `tt(*)'
+here cannot match anything that includes a match for `tt([[:upper:]])), nor
+will it complete `tt(B)' to `tt(fooBar)' (because there is no character in the
+current word to match var(coanchor)).
+
+Given the current word `tt(pass.n)' and a completion `tt(pass.byname)', the
+matcher `tt(L:.||[[:alpha:]]=by)' will produce the match `tt(pass.name)'.
+)
+enditem()
+)
+item(tt(x:))(
+
+Ignore this matcher and all matchers to its right.
+
+This matcher is used to mark the end of a match specification.  In a single
+standalone list of matchers, this has no use, but where match specifications
+are concatenated, as is often the case when using the
+ifzman(completion system (see 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.
+, it can allow one match specification to override another.
+)
+enditem()
 
 texinode(Completion Widget Example)()(Completion Matching Control)(Completion Widgets)
 sect(Completion Widget Example)
@@ -1185,5 +1196,5 @@ matches, e.g.:
 
 example(complete-files LPAR()RPAR() { compadd - * })
 
-This function will complete files in the current directory matching the 
+This function will complete files in the current directory matching the
 current word.
diff --git a/Test/Y02compmatch.ztst b/Test/Y02compmatch.ztst
index 621707482..4a0a1a060 100644
--- a/Test/Y02compmatch.ztst
+++ b/Test/Y02compmatch.ztst
@@ -378,15 +378,26 @@
   comp.graphics.rendering.misc comp.graphics.rendering.raytracing
   comp.graphics.rendering.renderman)
  test_code $example4_matcher example4_list
- comptest $'tst c.s.u\t'
-0:Documentation example using input c.s.u
+ comptest $'tst .s.u\t'
+0:r:|.=* should complete .s.u
+>line: {tst comp.sources.unix }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{21}
+
+  example4b_matcher='r:[^.]||.=* r:|=*'
+ test_code $example4b_matcher example4_list
+ comptest $'tst .s.u\t^[bc\t'
+0f:r:[^.]||.=* should not complete .s.u, but should complete c.s.u
+>line: {tst .s.u}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
 >line: {tst comp.sources.unix }{}
 >COMPADD:{}
 >INSERT_POSITIONS:{21}
 
  test_code $example4_matcher example4_list
- comptest $'tst c.g.\ta\t.\tp\ta\tg\t'
-0:Documentation example using input c.g.\ta\t.\tp\ta\tg\t
+ comptest $'tst .g.\ta\t.\tp\ta\tg\t'
+0f:r:|.=* should complete .g.
 >line: {tst comp.graphics.}{}
 >COMPADD:{}
 >INSERT_POSITIONS:{18}
@@ -424,9 +435,32 @@
 >COMPADD:{}
 >INSERT_POSITIONS:{32}
 
+ test_code $example4b_matcher example4_list
+ comptest $'tst .g.\t^[bc\t'
+0f:r:[^.]||.=* should not complete .g., but should complete c.g.
+>line: {tst .g.}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst comp.graphics.}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{18}
+
  test_code $example4_matcher example4_list
- comptest $'tst c...pag\t'
-0:Documentation example using input c...pag\t
+ comptest $'tst ...pag\t'
+0:r:|.=* should complete ...pag
+>line: {tst comp.graphics.apps.pagemaker }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{32}
+
+ test_code $example4b_matcher example4_list
+ comptest $'tst ...pag\t^[bc\t^Fg^F^Fa\t'
+0f:r:[^.]||.=* should not complete ...pag or c...pag, but should complete c.g.a.p
+>line: {tst ...pag}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst c...pag}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
 >line: {tst comp.graphics.apps.pagemaker }{}
 >COMPADD:{}
 >INSERT_POSITIONS:{32}
@@ -444,8 +478,8 @@
  example5_matcher='r:|[.,_-]=* r:|=*'
  example5_list=(veryverylongfile.c veryverylongheader.h)
  test_code $example5_matcher example5_list
- comptest $'tst  v.c\tv.h\t'
-0:Documentation example using input v.c\t
+ comptest $'tst  .c\t.h\t'
+0:r:|[.,_-]=* should complete .c and .h
 >line: {tst  veryverylongfile.c }{}
 >COMPADD:{}
 >INSERT_POSITIONS:{23}
@@ -453,6 +487,23 @@
 >COMPADD:{}
 >INSERT_POSITIONS:{44}
 
+ example5b_matcher='r:[^.,_-]||[.,_-]=* r:|=*'
+ test_code $example5b_matcher example5_list
+ comptest $'tst  .c\t^[bv\t.h\t^[bv\t'
+0f:r:[^.,_-]||[.,_-]=* should not complete .c or .h, but should complete v.c and v.h
+>line: {tst  .c}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst  veryverylongfile.c }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{23}
+>line: {tst  veryverylongfile.c .h}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst  veryverylongfile.c veryverylongheader.h }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{44}
+
 
  example6_list=(LikeTHIS FooHoo 5foo123 5bar234)
  test_code 'r:|[A-Z0-9]=* r:|=*' example6_list
@@ -493,16 +544,57 @@
  example7_matcher="r:[^A-Z0-9]||[A-Z0-9]=** r:|=*"
  example7_list=($example6_list)
  test_code $example7_matcher example7_list
- comptest $'tst H\t2\t'
-0:Documentation example using "r:[^A-Z0-9]||[A-Z0-9]=** r:|=*"
+ comptest $'tst H\t^BF\to\t2\t^B5\tb\t'
+0f:r:[^A-Z0-9]||[A-Z0-9]=** should not complete H, FH, 2 or 52, but should complete FoH and 5b2.
+>line: {tst H}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst F}{H}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
 >line: {tst FooHoo }{}
 >COMPADD:{}
 >INSERT_POSITIONS:{10}
+>line: {tst FooHoo 2}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst FooHoo 5}{2}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst FooHoo 5bar234 }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{18}
+
+ example7b_matcher="r:?||[A-Z0-9]=* r:|=*"
+ test_code $example7b_matcher example7_list
+ comptest $'tst H\t^BF2\t^B5\t'
+0f:r:?||[A-Z0-9]=* r:|=* should not complete H or 2, but should complete FH and 52.
+>line: {tst H}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst FooHoo }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{10}
+>line: {tst FooHoo 2}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
 >line: {tst FooHoo 5bar234 }{}
 >COMPADD:{}
 >INSERT_POSITIONS:{18}
 
 
+ example8_list=(passwd.byname)
+ test_code 'r:[^.]||.=* l:.||[^.]=*'
+ comptest $'tst .^B\tpass^Fname\t'
+0f:r:[^.]||.=* and l:.||[^.]=* should work symmetrically.
+>line: {tst }{.}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst passwd.byname }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{17}
+
+
  workers_7311_matcher="m:{a-z}={A-Z} r:|[.,_-]=* r:|=*"
  workers_7311_list=(Abc-Def-Ghij.txt Abc-def.ghi.jkl_mno.pqr.txt Abc_def_ghi_jkl_mno_pqr.txt)
  test_code $workers_7311_matcher workers_7311_list
@@ -537,11 +629,11 @@
 >COMPADD:{}
 >INSERT_POSITIONS:{5}
 
- workers_11081_matcher='m:{a-zA-Z}={A-Za-z} r:|[.,_-]=* r:[^A-Z0-9]||[A-Z0-9]=* r:[A-Z0-9]||[^A-Z0-9]=* r:[^0-9]||[0-9]=* r:|=*'
+ workers_11081_matcher='m:{a-zA-Z}={A-Za-z} r:|[.,_-]=* r:|=*'
  workers_11081_list=(build.out build.out1 build.out2)
  test_code $workers_11081_matcher workers_11081_list
  comptest $'tst bui\t\t\t'
-0:Bug from workers 11081
+0:Erratic completion bug from workers 11081: bui > build.out[] > build[.]out > build.out[] > build.out1[] > build.out2[]
 >line: {tst build.out}{}
 >COMPADD:{}
 >INSERT_POSITIONS:{13}
@@ -578,7 +670,7 @@
  workers_11586_list=(c00.abc c01.abc.def.00.0)
  test_code $workers_11586_matcher workers_11586_list
  comptest $'tst c00\t.\ta\t'
-0:Bug from workers 11586
+0:Disappearing characters bug from workers 11586: c00\t -> c0[], c00\t -> c0.abc[], c00.\t -> c0.abc[]
 >line: {tst c00}{}
 >COMPADD:{}
 >INSERT_POSITIONS:{6}
@@ -611,12 +703,12 @@
 >COMPADD:{}
 >INSERT_POSITIONS:{22}
 
- workers_13320_matcher='r:|[.,_-]=** r:[^0-9]||[0-9]=**'
+ workers_13320_matcher='r:|[.,_-]=**'
  workers_13320_list=(glibc-2.1.94-3.i386.rpm glibc-devel-2.1.94-3.i386.rpm)
  workers_13320_list=($workers_13320_list  glibc-profile-2.1.94-3.i386.rpm)
  test_code $workers_13320_matcher workers_13320_list
  comptest $'tst glibc-2.1\t'
-0:Test from workers 13320
+0:Incorrect cursor position bug from workers 13320: glibc-2.1\t -> glibc-2[.]1.94-3.i386.rpm
 >line: {tst glibc}{-2.1.94-3.i386.rpm}
 >COMPADD:{}
 >INSERT_POSITIONS:{9:27}
@@ -641,11 +733,11 @@
 >NO:{A.C}
 
 
- workers_13345b_matcher='r:|[.,_-]=** r:[^0-9]||[0-9]=**'
+ workers_13345b_matcher='r:|[.,_-]=** r:|[0-9]=**'
  workers_13345b_list=(a-b_1_2_2  a-b_2_0.gz a-b_2_0.zip)
  test_code $workers_13345b_matcher workers_13345b_list
  comptest $'tst a-b_2\t'
-0:Second test from workers 13345
+0:Disappearing character bug from workers 13345: a-b_2\t -> a-b__
 >line: {tst a-b_2_}{}
 >COMPADD:{}
 >INSERT_POSITIONS:{8:10}
-- 
2.33.1