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,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22563 invoked from network); 31 Mar 2021 18:37:50 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2021 18:37:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:Reply-To:Cc: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=dr08j5kJz+aeYwQM21D7DAcLYbV3C2XuEZP6/TtH5jk=; b=cILpMfZQFX4Rn+cQgMkqA9wiY7 ssizgzV6YCL0O7b5q33jbX3yYeJIrkPl+yoFIfb36V994GiA4dBB9ohZfA2BfAbcOlHO8kBwKmG3a +vD/qg3T15t2qXDf53Vhw6E1JcHF+snDnH3/zdC8srprE5rHoKaHJ2Anf040qNaA/rsmD0Geum/CP hRNTTDBlaFAJiY3vmiiRxUhWo8UVWX4ciRztodS4wY84qtDCzXPcrQLzWPN1e/K50PR5iOENEzYHE RTdkuFLMy6Z5nHTZFrrvaVXObBDUzIqRJxbS3k3iVXcG+HHkfPiGarQ5R8igCBLBWB2EmhZlBVw4/ KRuNQmPQ==; Received: from authenticated user by zero.zsh.org with local id 1lRfiv-000JhS-Qz; Wed, 31 Mar 2021 18:37:49 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1lRfie-000JXx-4t; Wed, 31 Mar 2021 18:37:32 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.93.0.4) (envelope-from ) id 1lRfid-000Gb7-Cw for zsh-workers@zsh.org; Wed, 31 Mar 2021 20:37:31 +0200 In-reply-to: <43E28449-DF6F-45B8-A503-63FDAF6B9653@kba.biglobe.ne.jp> From: Oliver Kiddle References: <476D5028-52A7-4850-98E7-95ADFA69367A@gmail.com> <56973-1617193890.190979@qzz3.XNO_.UryG> <43E28449-DF6F-45B8-A503-63FDAF6B9653@kba.biglobe.ne.jp> To: zsh-workers@zsh.org Subject: two anchor forms of matching control (was Re: Improvements to the gcc completion script) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63803.1617215851.1@hydra> Date: Wed, 31 Mar 2021 20:37:31 +0200 Message-ID: <63804-1617215851.398115@-o2b.AA7Q.6j2V> X-Seq: 48356 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: "Jun. T" wrote: > > It seems 'r:|[_-][^-]=* r:|=*' works _slightly_ better > > No. It doesn't work. It's easiest to view matching controls as converting the command-line into a pattern. [_-][^-] matches in --b at the second char position and because this is a right anchor, that's converted to -*-b* (second * is from cursor position) which in turn matches -foo-bar or --baz. I'm still inclined to think that 'r:[^-]||-=*' ought to work. Why that allows --b to match -foo-bar is a mystery to me. 'r:[^-]||-=X' does not allow it to match -X-b. In general, I wonder if there is some subtlty to the single * not matching anchors that I've missed. >From experimenting, it would seem that lanchor only needs to match the trial completion. This is documented for ranchor with l: but it could be more explicit. I get the impression that the intention at least is that where * rather than ** is used on the rhs, it is only the ranchor that it won't insert for r: and lanchor for l:. Again this could be more explicit in the documentation. The documentation patch also covers that but this is questionable because, assuming I've understood the intent, it is most definitely buggy. The one use of this by Sven was 'r:[^ A-Z0-9]||[ A-Z0-9]=*' 'r:|=*' for camel case and I think that reflects what it was intended to support. That allows anything before an initial uppercase character including other uppercase characters. 'r:|[:upper:]=* r:|=*' tends to work better in practice but also has quirks (consecutive uppercase) A good test pattern is compadd -M 'r:[A-N]||[O-Z]=* b:=*' ABCDEFGHIJKLMNOPQRSTUVWXYZ And then various two letter combinations on the command-line. Quite a few combinations produce results that I can't explain. Oliver diff --git a/Doc/Zsh/compwid.yo b/Doc/Zsh/compwid.yo index 0b98d07b2..3e86d3b42 100644 --- a/Doc/Zsh/compwid.yo +++ b/Doc/Zsh/compwid.yo @@ -959,6 +959,9 @@ 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. ) item(tt(x:))( This form is used to mark the end of matching specifications: @@ -1022,8 +1025,10 @@ 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. +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: