Re: Questions about completion matchers

[Oliver Kiddle <opk@xxxxxxx>]

Marlon Richert wrote:
> 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:

That's not what the implementation does in any real sense so I'm not
sure how helpful it is to reframe the regular expressions I gave in zsh
syntax. But the effect is along those basic lines if you view the
"transformed" $word as being a pattern that is matched against each of
the candidate matches in turn to decide which to present as matches.

I find it helpful as a brief reference but if it doesn't make sense to
you, ignore it.

> However, this leaves several transformations identical, which makes me believe
> I've misunderstood something.
>
> What did I miss?

The difference between b: and l: with an empty anchor (or e/r) is not
encapsulated by my regular expressions. They only differ in how strict
the anchoring to the start of the match is where another matching
control allowed extra characters to be inserted at the beginning.

The example given when this was added was zsh option completion where
underscores are ignored and a prefix of NO is allowed.

I took a look at the source code and dug out original -workers posts and
it does seem that the intention for the two anchor || forms was as I
thought. Even as designed I don't think either is ideal for camel case -
the l: form excludes characters from the wrong anchor for that.
The matching code looks a lot like regular expression matching with a
back tracking algorithm.

Oliver