From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4902 invoked from network); 8 Oct 2021 22:39:42 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 8 Oct 2021 22:39:42 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1633732782; b=T5qrEv0WGzuN5g/cL5z1WO3Jvea3PIEcbKBy+8QbstsXFg99CLW9MJc90ZyZ77AkVE0Znz0FX7 eBoBbhcBJIV04oBX37Kii9P93AefSx1RVuhM2ZEMDs2IWCsgCpwCDtZb5R9Ln67wBbAk3tuD0l fRm2Heup37WNVkYPMl1BUcFe0GXF+xELMaLPunvwb2CFsxGmWSgSbjlnjeslozidlxbKl7RUe+ FSqQD8xwAl9XUfnvaQNLoZYvoYTN1s5pWeB1IcThix0SRzHNdTJcKs5MEnG+QuzGJwhjY7iGTF S8LDZp3Z5VlpsrDp2MXcH0zwTi/fwzZaLzh5hG5qcwIGCA==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f46.google.com) smtp.remote-ip=209.85.217.46; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1633732782; bh=4fSooypg2muym9t4hi4YY/tYShYpHqLiyQnx74umxbc=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=AzJ9fLzWwJyck9zT6O52gtCPhW/aXyF0/Rm8yyTl+nXw6aQHqMtXrdtF5kFdLlw70GS0onuWko qPKs+Vx2oHsBOsAo+umqq2oKYWkucIXVRUlaHlW5VcwkahHH+zhKaUhVX5GSXLSO9uN8YNEJnv BkyjxDINVdFGXkq8Tt6CXFErit20mUle0jjT+2r1fSHCwvhDdIg2RIRG4nCKeq1J4noaAuwaR+ LWh7iGhf4ES97xruTNQwCqJF4lJCwiru3XRBLVuXkch0JIa8VzuWZRdB7pcDSYDPNuxbe3Nmb7 Jpx4L+h2w78yMoLOmcot8C6JwS0W0aYk301TK3YopZYuZg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=LqgRwVjO6gCQWb+2W4cStHvx+pO+timxK2AtdCyWnqM=; b=QkOHQwsXxrR6KvX13QfsLSY0wy mS8tdkB1idslCQ9/Fbz0/cD49koWFcVB2nCLYDxQ5VqfaOaTQf2WhVLCJavl7YevPqcVfjTBkjpHN S8nFS/HwwIwaog/5CTykBqVpPl5KpLtol/c9dlbQkrAvMabjV10TdC+rujDM+0WQQcIreiSLZGYVV tM+VVdPDlwRN4Vmt8BG51ubwKjukR0WGL4FNPjI4Ooun4zk8H7QvaW18yxyJILEj+IbgaHUYFWV9F i0j7LJ/qYivNhQm5btE+u9uBvLclkzqLGBc/FHGzS4fifhFa3D9Jc8QyjRdio3/IFe5/I7GNcWEjf ni0hnCFw==; Received: from authenticated user by zero.zsh.org with local id 1mYyWj-000MJb-BY; Fri, 08 Oct 2021 22:39:41 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f46.google.com) smtp.remote-ip=209.85.217.46; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-vs1-f46.google.com ([209.85.217.46]:40846) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1mYyVq-000Lc4-9l; Fri, 08 Oct 2021 22:38:46 +0000 Received: by mail-vs1-f46.google.com with SMTP id p18so12056108vsu.7; Fri, 08 Oct 2021 15:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LqgRwVjO6gCQWb+2W4cStHvx+pO+timxK2AtdCyWnqM=; b=JKl4+mLcs/hSB5q26JPoEtNkMygjI72LRPes4h9jIgzZi0NgEdnoHSN7tC7UXvvkb+ PaYaU0vGDqpn6Z99YpV/xOj+G/4HNBKamJDchH9l6g788x3ToolS4Fozj1hPuopXLu4l +2cr/BcgsCnlCpFMJ589eC/XwArOnQ3Tau86PQMa1M59/1n89dBRcy2kQBQIvrnuRX8E 52FAWkidSo7FA3as6pKCUSEMbzM4lhMOvxJQ11CviFAcW4M8KDPfc/a53Jg2JOe2OVFE zvqHqLWUxwij8kvTZHw+HYfcyZ5mE5uprZlCGiECtBRNUnB5ZID2YctPbnE2tDsaVD1U XdmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LqgRwVjO6gCQWb+2W4cStHvx+pO+timxK2AtdCyWnqM=; b=6Xg4WHnRF27hdqNkDXsayoGYU2gF7dm7cSVhaBo8t+bXUFCwrV1wljxntu8ciJOkNm ceYpnuf4EqSRx8Yjb85mVB2jUvZ6eeDbR4bpP+rLd4oKhVNDcrCFeWstx5aFZ0HGU1BG 7iOTMuHQX2X5Gff8cnF6C3mdRw93Ru4GeXlnrUWLyAlBng136kddyDyxUZeGnj2IK7f9 5YLLsHQRoV3MV1W+ORTkTEIwSieQR7Hrdw3tSGEVLqkkeB3uIF6YfqcwgHlqzMQIuXIC KIxaFS5e2r0Qk7yJlLUNqi+nO9Fr93MzuRseIDMWfh4RHDufM5NAFEAc3vD29lnfTRHi ZX/w== X-Gm-Message-State: AOAM532rIEQE5KJOoCyVmF+54RZ2mCdFvSldIns730NYJcw2WJsBYug9 e1j/3hdq+SYbo/eY8QGom9W8fx7GZSnLzkUk0O0vCcrvNZU= X-Google-Smtp-Source: ABdhPJz0IYl9cmT8mH2lZ0KzkCBKf6ksCOUDQ3Bmxh71btpLUYii60IQ+BqJJM8B1LqLedP2IUjLWpmcAVIz+nWAOBY= X-Received: by 2002:a05:6102:3a12:: with SMTP id b18mr14160250vsu.27.1633732724730; Fri, 08 Oct 2021 15:38:44 -0700 (PDT) MIME-Version: 1.0 References: <20296-1632661753.678317@ipjb.25sX.Whnd> In-Reply-To: <20296-1632661753.678317@ipjb.25sX.Whnd> From: Marlon Richert Date: Sat, 9 Oct 2021 01:38:08 +0300 Message-ID: Subject: Re: Questions about completion matchers To: Oliver Kiddle Cc: Zsh Users Content-Type: multipart/alternative; boundary="000000000000b730a405cddf0a9f" X-Seq: 27221 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: --000000000000b730a405cddf0a9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Oliver, for your long and thoughtful response. I'm afraid I don't quite understand all of it, though. Let me try to explain how I've understood things, but in a way that I find easier to process, and do please correct me where I'm wrong. The way I've understood it, is that, if $word contains the command line string for which completion is attempted, then each matcher should transform $word as follows: * m:$lpat=3D$tpat -> ${word//$~lpat/$~tpat} * b:$lpat=3D$tpat -> ${word/#$~lpat/$~tpat} * l:|$lpat=3D$tpat -> ${word/#$~lpat/$~tpat} * l:||$ranchor=3D$tpat -> ${word/#(#b)($~ranchor)/$~tpat$match[1]} * l:$lanchor|$lpat=3D$tpat -> ${word//(#b)($~lanchor)$~lpat/$match[1]$~tpat} * l:$lanchor||$ranchor=3D$tpat -> ${word//(#b)($~lanchor)($~ranchor)/$match[1]$~tpat$match[2]} * e:$lpat=3D$tpat -> ${word/%$~lpat/$~tpat} * r:$lpat|=3D$tpat -> ${word/%$~lpat/$~tpat} * r:$lanchor||=3D$tpat -> ${word/%(#b)($~lanchor)/$match[1]$~tpat} * r:$lpat|$ranchor=3D$tpat -> ${word//(#b)$~lpat($~ranchor)/$~tpat$match[1]} * r:$lanchor||$ranchor=3D$tpat -> ${word//(#b)($~lanchor)($~ranchor)/$match[1]$~tpat$match[2]} However, this leaves several transformations identical, which makes me believe I've misunderstood something. What did I miss? On Sun, Sep 26, 2021 at 4:09 PM Oliver Kiddle wrote: > > Marlon Richert wrote: > > How can I make a matcher that completes the right-most part (and only > > the right-most part) of each subword? That is, given a target > > completion 'abcDefGhi', how do I make a match specification that > > completes inputs > > If you're trying to do camel-case matching, one option is: > 'r:|[A-Z]=3D* r:|=3D*' > > The following was used by the original creator of matching control, it > works and breaks for the same cases as above in your example: > 'r:[^ A-Z0-9]||[ A-Z0-9]=3D* r:|=3D*' > > These allow extra characters at the beginning. So in your example, D > and DG match the target. There are also oddities with consecutive runs > of upper case characters, consider e.g. completion after ssh -o where > there is, e.g. "TCPKeepAlive" as an option. TKA won't match but ideally > would. > > With matching control, it is often easiest if you view it as converting > what is on the command-line into a regular expression. I haven't probed > the source code to get a precise view of how these are mapped. For my > own purposes, I keep a list but don't trust it in all cases because I've > found contradictory examples and tweaked it more than once, perhaps > making it less accurate in the process. So with the caveat that this > may contain errors, my current list is as follows: > > Not that that starting point is: > [cursor position] =E2=86=92 .* > Then: > 'm:a=3Db' =E2=80=93 a =E2=86=92 b (* doesn't work= on rhs) > 'r:|b=3D*' =E2=80=93 b =E2=86=92 [^b]*b > 'r:a|b=3D*' =E2=80=93 ab =E2=86=92 [^b]*a?b > 'r:a|b=3Dc' - ab =E2=86=92 cb > 'l:a|=3D*' =E2=80=93 a =E2=86=92 [^a]*a > 'l:a|b=3D*' =E2=80=93 ab =E2=86=92 [^a]*ab? > 'l:a|b=3Dc' =E2=80=93 ab =E2=86=92 ac > 'b:a=3D*' =E2=80=93 ^a =E2=86=92 .* > 'b:a=3Dc' =E2=80=93 ^a =E2=86=92 ^c > 'e:a=3D*' =E2=80=93 a$ =E2=86=92 .* > 'r:a||b=3D*' =E2=80=93 b =E2=86=92 [^a]*ab (only * works o= n rhs, empty a or b has no use) > 'l:a||b=3D*' =E2=80=93 ^a =E2=86=92 a.* (only * on rhs,= empty a no use, b ignored?!) > > Something like [A-Z] becomes it's concrete form from the command-line in the regex > For correspondence classes, the corresponding form goes in the regex and only work with m:/M: forms. > ** is like * but with .* instead of [^x]* > > In all cases, the original unchanged form also passes - a matching > control does not have to be used. I've excluded those in the regular > expressions above. But including them note the following potentially > useful effects with an empty lpat: > > 'r:|b=3Dc' =E2=80=93 b =E2=86=92 c?b > 'l:a|=3Dc' =E2=80=93 a =E2=86=92 ac? > > When composing multiple matching controls, it doesn't try to apply over > the results of the previous. You can consider it an alternation of the > effect of each matching control. > > So 'r:a|b=3D* l:a|b=3D*' would be: ab =E2=86=92 (ab|[^b]*a?b|[^a]*ab?) > > For the most part there are certain common forms and if you stick to > those, you find fewer bugs than when being creative. > > The || forms seem buggy to me. From the documentation, my assumption > would be that one means a[^a]*b and the other a[^b]*b > That could be more helpful for camel-case but I would need to generate > tests to say for sure. > b seems to even be ignored for the l form. > > > Additionally, the following are unclear to me from the manual: > > * What is the exact difference between l:lanchor||ranchor=3Dtpat and > > r:lanchor||ranchor=3Dtpat ? > > From the documentation and assuming some actual symmetry I would assume > the difference to be that lanchor needs to match the completion > candidate but not the command-line, while a tpat of * will not match > ranchor =E2=80=93 swap l and r anchors for l and r forms in the descripti= on. > If that's what it did do, it might possibly bring us closer to a good > solution for camel-case matching. > > But as the regex above indicates, that isn't the case. I don't really > see the logic of the l:lanchor||ranchor=3Dtpat seeming to be anchored to > the beginning. I think those forms came about as an attempt to get > camel-case to work. > > > * Why do the examples in the manual add r:|=3D* to the end of each > > matcher? This appears to make no difference at all. > > For the case where the cursor is in the middle rather than the end. For > the example from the manual with Usenet group names like > comp.sources.unix, try c.s.u with the cursor after the s. > > There are three components. Two have a dot anchor at the end. The final > has an end-of-string anchor. > > > * It appears that the order of "match descriptions" in a matchers > > matters, but it is unclear to me in what way and it isn't mentioned in > > the manual. For example, the pairs of matchers below differ only in > > the order of their match descriptions, yet each produces a different > > behavior. How are the match descriptions inside a matcher evaluated > > and what causes the difference between these? > > Order shouldn't really matter (apart from the x: matcher). > > As I mention earlier, you can consider it as being the alternaton of all > of them - at every point in the command-line where one of them can do > something. So a single match may rely on more than one matching control > to be matched. I can imagine that order might matter where you have mixed > up anchors. An example would be interesting. > > > * 'r:|[[:punct:]]=3D** l:?|=3D[[:punct:]]' completes 'cd a/b' to 'cd > > a/bc', but 'l:?|=3D[[:punct:]] r:|[[:punct:]]=3D**' does not. > > In my testing, neither do. Where is the cursor? You can think of the > matching as adding .* at the cursor position so a/b completes to a/bc > with no matching control if the cursor is at the end. The lack of other > candidate completions can also confuse testing of this because with > prefix completion, a/bc can be the only unambiguous match. Are you sure > you don't have other customisations that is allowing the first case to > match. > > The l: pattern allows punctuation after any character so a/b becomes the > pattern a(|[[:punct:]])/(|[[:punct:]])b(|[[:punct:]]) > > The r: pattern allows anything before the punctuation so a/b becomes the > pattern a*/b > > > * Given two target completions 'a-b' and 'a_b', both 'l:?|=3D[-_] > > m:{-}=3D{_}' and 'm:{-}=3D{_} l:?|=3D[-_]' will insert 'a-b' as the > > unambiguous substring on the first try, but on the second try, only > > the former will then list both completions, whereas the latter will > > complete only 'a-b'. > > I'm not sure I follow what you mean by the first and second try. If you > mean a second press of , matching is done completely anew with the > new command-line contents. > > With just compadd -M 'l:?|=3D[_-]' - a-b a_b > ab offers both candidates as matches. > Adding 'm:-=3D_' in just means that completion after a-b will also match > a_b > Single element correspondence classes are pointless by the way. > > Especially with the uppercase forms (L: etc) it is easy to create > situations where an unambiguous substring is inserted and the set of > candidate matches is quite different with the new command-line contents. > The effect can be somewhat jarring and has the appearance of a bug. > > Oliver --000000000000b730a405cddf0a9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Oliver, for your long and= thoughtful response. I'm afraid I don't quite understand all of it= , though. Let me try to explain how I've understood things, but in a wa= y that I find easier to process, and do please correct me where I'm wro= ng.

The way I've understood it, is that, if=C2=A0$word contains= the command line string for which completion is attempted,=C2=A0then each = matcher should transform $word as follows:

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 m:$lpat=3D$tpat -> ${word//$~lpat/$~tpat}

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 b:$lpat=3D$tpat ->=C2=A0${word/#$~lpat/$~tpat}
*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= l:|$lpat=3D$tpat -> ${word/#$~lpat/$~tpat}
*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0l:||$ranchor=3D$tpat = -> ${word/#(#b)($~ranchor)/$~tpat$match[1]}
*=C2=A0 =C2=A0 =C2=A0= l:$lanchor|$lpat=3D$tpat -> ${word//(#b)($~lanchor)$~lpat/$match[1]$~tpa= t}
* l:$lanchor||$rancho= r=3D$tpat -> ${word//(#b)($~lanchor)($~ranchor)/$match[1]$~tpat$match[2]= }

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e:$lpat=3D$tpa= t ->=C2=A0${word/%$~lpat/$~tpat}
*=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r:$lpat|=3D$tpat -> ${word/= %$~lpat/$~tpat}
*=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0r:$lanchor||=3D$tpat -> ${word/%(#b)($~lanchor)/$match[1]$~tpat}
*=C2=A0 =C2=A0 =C2=A0r:$lpat|$ranchor=3D$tpat -> ${word//(#b)$~lpat= ($~ranchor)/$~tpat$match[1]}
* r:$lanchor||$ranchor=3D$tpat ->=C2=A0${word//(#b)($~lanchor)($~rancho= r)/$match[1]$~tpat$match[2]}

However, this leaves several transformations identical, whic= h makes me believe I've misunderstood something.

What did= I miss?


On Sun, Sep 26, 2021 at 4:09 PM Oliver Kiddle &l= t;opk@zsh.org> wrote:
>
>= Marlon Richert wrote:
> > How can I make a matcher that completes= the right-most part (and only
> > the right-most part) of each su= bword? That is, given a target
> > completion 'abcDefGhi',= how do I make a match specification that
> > completes inputs
= >
> If you're trying to do camel-case matching, one option is:=
> =C2=A0 'r:|[A-Z]=3D* r:|=3D*'
>
> The followin= g was used by the original creator of matching control, it
> works an= d breaks for the same cases as above in your example:
> =C2=A0 'r= :[^ A-Z0-9]||[ A-Z0-9]=3D* r:|=3D*'
>
> These allow extra c= haracters at the beginning. So in your example, D
> and DG match the = target. There are also oddities with consecutive runs
> of upper case= characters, consider e.g. completion after ssh -o where
> there is, = e.g. "TCPKeepAlive" as an option. TKA won't match but ideally=
> would.
>
> With matching control, it is often easiest = if you view it as converting
> what is on the command-line into a reg= ular expression. I haven't probed
> the source code to get a prec= ise view of how these are mapped. For my
> own purposes, I keep a lis= t but don't trust it in all cases because I've
> found contra= dictory examples and tweaked it more than once, perhaps
> making it l= ess accurate in the process. So with the caveat that this
> may conta= in errors, my current list is as follows:
>
> Not that that sta= rting point is:
> =C2=A0 [cursor position] =E2=86=92 .*
> Then:=
> =C2=A0 'm:a=3Db' =C2=A0 =C2=A0 =C2=A0 =E2=80=93 a =C2=A0 = =C2=A0 =E2=86=92 b =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (* doesn't= work on rhs)
> =C2=A0 'r:|b=3D*' =C2=A0 =C2=A0 =C2=A0=E2=80= =93 b =C2=A0 =C2=A0 =E2=86=92 [^b]*b
> =C2=A0 'r:a|b=3D*' =C2= =A0 =C2=A0 =E2=80=93 ab =C2=A0 =C2=A0=E2=86=92 [^b]*a?b
> =C2=A0 '= ;r:a|b=3Dc' =C2=A0 =C2=A0 - ab =C2=A0 =C2=A0=E2=86=92 cb
> =C2=A0= 'l:a|=3D*' =C2=A0 =C2=A0 =C2=A0=E2=80=93 a =C2=A0 =C2=A0 =E2=86=92= [^a]*a
> =C2=A0 'l:a|b=3D*' =C2=A0 =C2=A0 =E2=80=93 ab =C2= =A0 =C2=A0=E2=86=92 [^a]*ab?
> =C2=A0 'l:a|b=3Dc' =C2=A0 =C2= =A0 =E2=80=93 ab =C2=A0 =C2=A0=E2=86=92 ac
> =C2=A0 'b:a=3D*'= =C2=A0 =C2=A0 =C2=A0 =E2=80=93 ^a =C2=A0 =C2=A0=E2=86=92 .*
> =C2=A0= 'b:a=3Dc' =C2=A0 =C2=A0 =C2=A0 =E2=80=93 ^a =C2=A0 =C2=A0=E2=86=92= ^c
> =C2=A0 'e:a=3D*' =C2=A0 =C2=A0 =C2=A0 =E2=80=93 a$ =C2= =A0 =C2=A0=E2=86=92 .*
> =C2=A0 'r:a||b=3D*' =C2=A0 =C2=A0=E2= =80=93 b =C2=A0 =C2=A0 =E2=86=92 [^a]*ab =C2=A0 =C2=A0 =C2=A0 (only * works= on rhs, empty a or b has no use)
> =C2=A0 'l:a||b=3D*' =C2= =A0 =C2=A0=E2=80=93 ^a =C2=A0 =C2=A0=E2=86=92 a.* =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (only * on rhs, empty a no use, b ignored?!)
>
> Som= ething like [A-Z] becomes it's concrete form from the command-line in t= he regex
> For correspondence classes, the corresponding form goes in= the regex and only work with m:/M: forms.
> ** is like * but with .*= instead of [^x]*
>
> In all cases, the original unchanged form= also passes - a matching
> control does not have to be used. I'v= e excluded those in the regular
> expressions above. But including th= em note the following potentially
> useful effects with an empty lpat= :
>
> =C2=A0 'r:|b=3Dc' =C2=A0 =C2=A0 =C2=A0=E2=80=93 b= =C2=A0 =C2=A0 =E2=86=92 c?b
> =C2=A0 'l:a|=3Dc' =C2=A0 =C2= =A0 =C2=A0=E2=80=93 a =C2=A0 =C2=A0 =E2=86=92 ac?
>
> When comp= osing multiple matching controls, it doesn't try to apply over
> = the results of the previous. You can consider it an alternation of the
&= gt; effect of each matching control.
>
> So 'r:a|b=3D* l:a|= b=3D*' would be: ab =E2=86=92 (ab|[^b]*a?b|[^a]*ab?)
>
> Fo= r the most part there are certain common forms and if you stick to
> = those, you find fewer bugs than when being creative.
>
> The ||= forms seem buggy to me. From the documentation, my assumption
> woul= d be that one means a[^a]*b and the other a[^b]*b
> That could be mor= e helpful for camel-case but I would need to generate
> tests to say = for sure.
> b seems to even be ignored for the l form.
>
>= ; > Additionally, the following are unclear to me from the manual:
&g= t; > * What is the exact difference between l:lanchor||ranchor=3Dtpat an= d
> > r:lanchor||ranchor=3Dtpat ?
>
> From the documen= tation and assuming some actual symmetry I would assume
> the differe= nce to be that lanchor needs to match the completion
> candidate but = not the command-line, while a tpat of * will not match
> ranchor =E2= =80=93 swap l and r anchors for l and r forms in the description.
> I= f that's what it did do, it might possibly bring us closer to a good> solution for camel-case matching.
>
> But as the regex ab= ove indicates, that isn't the case. I don't really
> see the = logic of the l:lanchor||ranchor=3Dtpat seeming to be anchored to
> th= e beginning. I think those forms came about as an attempt to get
> ca= mel-case to work.
>
> > * Why do the examples in the manual = add r:|=3D* to the end of each
> > matcher? This appears to make n= o difference at all.
>
> For the case where the cursor is in th= e middle rather than the end. For
> the example from the manual with = Usenet group names like
> comp.sources.unix, try c.s.u with the curso= r after the s.
>
> There are three components. Two have a dot a= nchor at the end. The final
> has an end-of-string anchor.
>> > * It appears that the order of "match descriptions" in= a matchers
> > matters, but it is unclear to me in what way and i= t isn't mentioned in
> > the manual. For example, the pairs of= matchers below differ only in
> > the order of their match descri= ptions, yet each produces a different
> > behavior. How are the ma= tch descriptions inside a matcher evaluated
> > and what causes th= e difference between these?
>
> Order shouldn't really matt= er (apart from the x: matcher).
>
> As I mention earlier, you c= an consider it as being the alternaton of all
> of them - at every po= int in the command-line where one of them can do
> something. So a si= ngle match may rely on more than one matching control
> to be matched= . I can imagine that order might matter where you have mixed
> up anc= hors. An example would be interesting.
>
> > =C2=A0 * 'r= :|[[:punct:]]=3D** l:?|=3D[[:punct:]]' completes 'cd a/b' to &#= 39;cd
> > a/bc', but 'l:?|=3D[[:punct:]] r:|[[:punct:]]=3D= **' does not.
>
> In my testing, neither do. Where is the c= ursor? You can think of the
> matching as adding .* at the cursor pos= ition so a/b completes to a/bc
> with no matching control if the curs= or is at the end. The lack of other
> candidate completions can also = confuse testing of this because with
> prefix completion, a/bc can be= the only unambiguous match. Are you sure
> you don't have other = customisations that is allowing the first case to
> match.
>> The l: pattern allows punctuation after any character so a/b becomes = the
> pattern a(|[[:punct:]])/(|[[:punct:]])b(|[[:punct:]])
>> The r: pattern allows anything before the punctuation so a/b becomes= the
> pattern a*/b
>
> > =C2=A0 * Given two target co= mpletions 'a-b' and 'a_b', both 'l:?|=3D[-_]
> &g= t; m:{-}=3D{_}' and 'm:{-}=3D{_} l:?|=3D[-_]' will insert '= a-b' as the
> > unambiguous substring on the first try, but on= the second try, only
> > the former will then list both completio= ns, whereas the latter will
> > complete only 'a-b'.
&g= t;
> I'm not sure I follow what you mean by the first and second = try. If you
> mean a second press of <tab>, matching is done co= mpletely anew with the
> new command-line contents.
>
> W= ith just compadd -M 'l:?|=3D[_-]' - a-b a_b
> ab<tab> o= ffers both candidates as matches.
> Adding 'm:-=3D_' in just = means that completion after a-b will also match
> a_b
> Single = element correspondence classes are pointless by the way.
>
> Es= pecially with the uppercase forms (L: etc) it is easy to create
> sit= uations where an unambiguous substring is inserted and the set of
> c= andidate matches is quite different with the new command-line contents.
= > The effect can be somewhat jarring and has the appearance of a bug.>
> Oliver

<= /div>
--000000000000b730a405cddf0a9f--