Re: [PATCH] completion: matcher correspondence classes: fix offset

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, Dec 23, 2021 at 12:25 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> Were there ever any follwoups to this?

I don't recall seeing any.  Probably the only thing desirable beyond
that patch would be a regression test.

In the original message:
> > a) Why does "cfp_matcher_range" do nothing if more than
> >   one matcher spec is given?

It's not that it does nothing, it's that it never gets called by
cfp_matcher_pats() when there is a matcher-list style but not a
matcher style.  I haven't worked through exactly why THAT happens, but
it has to do with whether there's anything left over after the loop in
cfp_matcher_pats().  I have noticed that the "compadd -D" pass behaves
the same way regardless of the styles:  cfp_matcher_pats() loops
through the matcher spec and ends up with nothing left at the end, so
cfp_matcher_range() is not called.

> > b) Do we even need the "cfp_matcher_range" function
> >   at all? Seems like the later compadd -D works

Although _path_files is the only function that currently calls
compfiles -p, that doesn't mean no other function ever might ... so
what would happen if the compadd -D were never done?

> > c) Why does _path_files duplicate all matcher-list
> >   entries when calling "compfiles -p"?

It doesn't appear to duplicate matcher-list entries ... what it does
is build its own list of matchers from its -M option, the "expl" value
returned by _description, and the setting of nocaseglob, and then
appends that to the matcher-list passed down from _main_complete.
That may or may not duplicate parts of the matcher-list.  I suppose
_path_files could scan the $_matcher global to be sure it doesn't
append something that is already there ...?