---------- Forwarded message --------- From: Dan Arad Date: Sun, May 17, 2020, 11:05 Subject: Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases To: Daniel Shahaf 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 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 ». > > 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@gmail.com