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

[Marlon Richert <marlon.richert@gmail.com>]

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

On Mon, Oct 11, 2021 at 5:34 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> The tests show how :||= matchers should behave in order to provide
> completion features that cannot be implemented with :|= matchers.
>
> This is a follow-up to users/27228.

I've now added an accompanying documentation update to the patch.

[-- Attachment #2: 0001-Add-xfail-tests-for-form-of-completion-matchers.txt --]
[-- Type: text/plain, Size: 29640 bytes --]

From 3ec2fceced1f327eb2ac7484772bd1d3756bf8d2 Mon Sep 17 00:00:00 2001
From: Marlon Richert <marlon.richert@gmail.com>
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 @@
   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:Documentation example using input .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:Documentation example using input .s.u but with double anchor
+>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'
+0:Documentation example using input .g.\ta\t.\tp\ta\tg\t
 >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:Documentation example using input .g. with double anchor
+>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:Documentation example using input ...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:Documentation example using input ...pag with double anchor
+>line: {tst .g.}{}
+>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:Documentation example using input .c
 >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'
+0f:Documentation example using input .c but with double anchor
+>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,15 +544,52 @@
  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\to2\t^[b5\tb\t'
+0f:Documentation example using "r:[^A-Z0-9]||[A-Z0-9]=** r:|=*"
+>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:Documentation example using "r:?||[A-Z0-9]=* r:|=*"
+>line: {tst H}{}
+>COMPADD:{}
+>INSERT_POSITIONS:{}
+>line: {tst FooHoo }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{10}
+>line: {tst FooHoo 5bar234 }{}
+>COMPADD:{}
+>INSERT_POSITIONS:{18}
+
+ example8_list=(passwd.byname)
+ test_code 'r:[^.]||.=* l:.||[^.]=*'
+ comptest $'tst .^B\tpass^Fname\t'
+0f:Symmetry between r and l
+>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)
-- 
2.33.0