zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: zsh-workers@zsh.org
Subject: two anchor forms of matching control (was Re: Improvements to the gcc completion script)
Date: Wed, 31 Mar 2021 20:37:31 +0200	[thread overview]
Message-ID: <63804-1617215851.398115@-o2b.AA7Q.6j2V> (raw)
In-Reply-To: <43E28449-DF6F-45B8-A503-63FDAF6B9653@kba.biglobe.ne.jp>

"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:
 


      reply	other threads:[~2021-03-31 18:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12  4:07 Improvements to the gcc completion script Jacob Gelbman
2021-03-19  3:51 ` Jun T
2021-03-22  2:28   ` Jacob Gelbman
2021-03-22  2:29     ` Jacob Gelbman
2021-03-22 15:18     ` Jun. T
2021-03-31 12:31       ` Oliver Kiddle
2021-03-31 14:53         ` Jun. T
2021-03-31 15:06           ` Jun. T
2021-03-31 18:37             ` Oliver Kiddle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63804-1617215851.398115@-o2b.AA7Q.6j2V \
    --to=opk@zsh.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).