Re: Strange completion display with wrong matcher-list

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Martin Vaeth wrote:
> Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> >
> > [...] there's a problem in your _my function
>
> You are right, my guess about the cause was wrong.
> There remains the change of behaviour between zsh versions:
>
> > _arguments added matches, _files didn't
>
> In my original example (which I had unfortunately shortened
> for the posting), I had passed to the _arguments function
> the option -A '-*'.

The purpose of the -A option is something different: it is to indicate
that no further options should be completed after a word that matches
that pattern. Consider something like:
  grep pattern -l file

Some commands allow the -l to be positioned after the normal argument,
others don't. Whether a command allows this is typically independent of
whether it allows for the normal argument to start with a dash. So while
grep allows -l in the later position, if your pattern starts with -, you
need grep -- -pattern.

Even for a command where -A '-*' is appropriate, I don't think it would
be right to assume that the rest arguments can't be completed if the
current word matches the pattern. For one thing the pattern can be
anything, '*:' perhaps and for the purposes of completion it is a fair
bet to assume that at the cursor position, things are incomplete so a
trailing colon might be meant as something in the middle.

Also, an initial - is typically actually valid in things like files and
patterns so it wouldn't be right to not try to complete them. Also,
with approximate completion and matching control, an initial typed dash
doesn't necessarily imply that the match has to have an initial dash.

Does it cause problems in the case of your function? If completion of
the normal arguments is slow it'd be reasonable to do an explicit
pattern match on the current word.

> In zsh-5.2, this was indeed the case (at least with -A '-*');
> in zsh-5.3 it is no longer so (and so the _my function becomes
> faulty for the reasons you explained).
>
> Perhaps the cause is the following "bugfix":

Actually, it's due to:
  * 39026: pattern specified with _arguments' -A option shouldn't be
  checked against words after the cursor

I'm fairly sure that the original behaviour was not intentional but due
to forgetting to consider the case of the cursor being somewhere other
than the end of the line (not an uncommon mistake).

Oliver