Thanks for the great clarifications! I'll try to stick to the correct technical terms. 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. ... 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. I suspected as much, but I'm new to zsh and completion, so I had some hard time following the debug logs and figuring this out. _python_or_script() { > _python_script_words_backup > _python "$@" && _compskip=all > } > compdef _python_or_script python This works like a charm! The only thing I did different is to use the `#compdef -p` form at the beginning of the file so I could give the same pattern as that of the `_python` function. > 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. This `_compskip` prevents the inner `_dispatch` from calling the `_python_script` function more than once. An example I've seen, is with the command line `python .vscode/ps.py` (I use the .vscode directory as a place for temporary files as it is git ignored). In this case, without `_compskip=all`, the inner `_dispatch` calls `_python_script` once with `service=.vscode/ps.py` and once with `service=ps.py`. In my case this doubles the time to produce completions which may be critical depending on the way the user has written his script. To conclude, I would really like to thank everybody who took part in this discussion. This is my first open source project, and I was really hoping to provide a good user experience. It was a great experience for me to have such a productive conversation, and I really appreciate the time you've put into providing detailed answers in a welcoming manner. Have a great day! Dan On Mon, May 18, 2020 at 1:14 AM Bart Schaefer wrote: > On Sun, May 17, 2020 at 3:12 PM Bart Schaefer > wrote: > > > > aborts the current level of _dispatch but doesn't prevent the outer > > _default that called _python from continuing on into -default-, which > > Typo, that should say "... the outer _dispatch that ..." > -- Dan Arad dan1994@gmail.com