From 3ec2fceced1f327eb2ac7484772bd1d3756bf8d2 Mon Sep 17 00:00:00 2001 From: Marlon Richert 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