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

[Dan Arad <dan1994@xxxxxxxxx>]

---------- Forwarded message ---------
From: Dan Arad <dan1994@xxxxxxxxx>
Date: Sun, May 17, 2020, 11:05
Subject: Re: Help Request/Bug Report: comparguments causes _arguments to
fail in certain cases
To: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>


I think you're mixing things up, so I'll try to clarify:

The only thing I do in the `-first-` script is to backup `words` in another
variable. Otherwise it doesn't affect the completion flow (and my other
bug) at all.
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.

To make things easier to understand, my main script is called
`_python_script`, and the `-first-` script is called
`_python_script_words_backup`.

The two scenarios (starting from the first thing called by `_complete`):

Given the command line `./ps.py`:
`_python_script_words_backup`: Backs up `words` and returns to `_complete`
`_complete`: Calls `_normal` which calls `_dispatch` which  calls
`_python_script`
`_python_script`: Uses the first item in the `words` variable to determine
the what is the script

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`
`_python_script`: Uses the updated `words` the same as in the first
scenario to determine which script is run, and adds the actual completion

How would that help if it existed?  I assume -first- runs before
> _python, not after, so 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
and not before. I also use `_compskip=all` and always return 0, but since
it is after `_python` has already run, it doesn't solve this particular
problem.

In short, if I want to bypass `_python`, I would probably have to change my
`compdef` definition from `-P *.py` to `-P *`, but then I'll have to parse
everything myself again, losing the great advantage `_python` has given me.

I also thought about using the `_ignore` directive, but I'm not exactly
sure how to use it, or if it can even be used for this use case.

And about this:

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`? Using something like `-p *` is not right for
this case, as it will be called multiple times (including after `_python`
has run) and will overwrite the backup.

Cheers,
Dan

On Sat, May 16, 2020 at 11:48 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
wrote:

> Dan Arad wrote on Fri, 15 May 2020 17:39 +0300:
> > I got it working using the hook method: I added another script with
> > `#compdef -first-` that saves the words array.
> >
>
> Nice :)
>
> > The thing is, that now I'm faced with a different problem:
> > When the command line is `./ps.py`, completions are generated correctly.
> > 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.
> >
> > 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.
>
> How would that help if it existed?  I assume -first- runs before
> _python, not after, so 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?
>
> Or you could arrange for «python ps.py» to call your script without
> a -first- completion function.  That should prevent _python from
> falling back to completing files.  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.
>
> > 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>».
>
> I don't recall offhand how to disable or modify the fallback behaviour.
>
> > Thanks for all the help,
> > Dan
>
> You're welcome.
>
> Cheers,
>
> Daniel
>
> P.S. While I wrote the above I ran into this:
>
> diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
> index 98ab46d8a..8d2813c5a 100644
> --- a/Doc/Zsh/compsys.yo
> +++ b/Doc/Zsh/compsys.yo
> @@ -1685,6 +1685,9 @@ example(zstyle ':completion:*' group-name '')
>
>  All matches for which no group name is defined will be put in a group
>  named tt(-default-).
> +
> +To display the group name in the output, see the tt(format) style (q.v.)
> +under the tt(descriptions) tag.
>  )
>  kindex(group-order, completion style)
>  item(tt(group-order))(
>


-- 
Dan Arad
dan1994@xxxxxxxxx