Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases

[Bart Schaefer <schaefer@brasslantern.com>]

Reordering discussion slightly ...

On Sat, May 16, 2020 at 1:49 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Dan Arad wrote on Fri, 15 May 2020 17:39 +0300:
> > The thing is, that now I'm faced with a different problem:
> > When the command line is `python ps.py`, the actual completions are joined
> > by the list of files in the current directory.
> >
> > This appears to be a byproduct of going through the `_python`
> > auto-completion script.
> >
> > Also, might this be a bug in the `_python` completion script?
>
> I don't see how.  It's normal for completion to offer files as a
> fallback for unknown commands, as in «nosuchcommand <TAB>».

This isn't happening because of an unknown command, it's because the
historic behavior of _normal is to return all files when none match
the specific completer.  I've mentioned this before; the thought at
the time was that it would be even more confusing for completion to
beep failure at you when there was at least one file in the directory.

> > I was wondering if there is a way to remove existing completion matches
> > before adding my own to make sure I provide only correct matches.
>
> I don't think there's a way to remove already-added matches.

Completers that want to do this sort of thing typically do a hack:
Wrap the "compadd" builtin with a function that uses "builtin compadd
-O array" (or "-A array") to capture the completions without actually
adding them, and then later remove the wrapper and make the real
compadd call.  However, I don't think you need or want to do that
here.

On Sun, May 17, 2020 at 12:26 PM Dan Arad <dan1994@gmail.com> wrote:
>
> The `_python` script is called before my script (assuming your command line
> starts with python), and I actually use it to my advantage, since it
> updates `words` so that the script name is always the first element, making
> my job easier.

I think you're mis-stating this.  The _python function (I'm going to
be pedantic that a function is not the same as a script) is called
AROUND your _python_script function.  You have this call sequence
correct:

> Given the command line `python ./ps.py`:
> `_python_script_words_backup`: Backs up `words` and returns to `_complete`
> `_complete`: Calls `_normal` which calls `_dispatch` which  calls `_python`
> `_python`: Adds its own arguments, shifts `words` and calls `_normal` which
> calls `_dispatch` which calls `_python_script`

However, nothing will have been "compadd"ed by _python at the point at
which it calls _normal.  Anything that gets added is being added as
consequence of calling _normal, not as a consequence of calling
_python.

> [Daniel Shahaf again in a later message]:
> > you should look for a way to prevent _python from
> > running when your function has added matches.  For starters, does your
> > function return 0 when it has added matches?
>
> So regarding what you wrote here, I add my matches after `_python` has run

No, you add them while _python is still running, not after.

> and not before. I also use `_compskip=all`

That doesn't actually do very much once you are beyond -first-.  It
aborts the current level of _dispatch but doesn't prevent the outer
_default that called _python from continuing on into -default-, which
I think you'll find to be the place your extra matches are coming
from.

> and always return 0, but since
> it is after `_python` has already run, it doesn't solve this particular
> problem.

What you would need here is for _python to set _compskip, because it's
local to each level of _dispatch.

> > Additionally, overwriting -first- is
> > not a composable approach: users who already overwrite -first- won't be
> > able to install your completion function alongside their existing
> > configuration.
>
> Would you propose using a different `compdef` specification for
> `_python_script_words_backup`?

No, I'd suggest using a different compdef for "python" itself.  E.g.:

_python_or_script() {
  _python_script_words_backup
  _python "$@" && _compskip=all
}
compdef _python_or_script python

(and remove your -first- compdef).