I'm using todoman <https://github.com/pimutils/todoman> and it provides a useful completion for ZSH (I happen to be the writer of it): <https://github.com/pimutils/todoman/blob/master/contrib/completion/zsh/_todo> TIL there's another completion file in ZSH's tree that has `#compdef todo` among other common aliases for it: https://gitlab.com/zsh-org/zsh/-/blob/5c55b3fb50bbfe602fcfa55fa6258e398ecc6b20/Completion/Unix/Command/_devtodo I'm using NixOS and this is my `$fpath`: ~/.zsh/comp/tested ~/.zsh/comp/local /usr/local/share/zsh/site-functions /nix/store/k9rq1cymsrbfybzgx21c5g851085w0fz-zsh-5.7.1/share/zsh/site-functions /nix/store/k9rq1cymsrbfybzgx21c5g851085w0fz-zsh-5.7.1/share/zsh/5.7.1/functions /run/current-system/sw/share/zsh/site-functions /run/current-system/sw/share/zsh/5.7.1/functions /run/current-system/sw/share/zsh/vendor-completions /nix/var/nix/profiles/default/share/zsh/site-functions /nix/var/nix/profiles/default/share/zsh/5.7.1/functions /nix/var/nix/profiles/default/share/zsh/vendor-completions /etc/profiles/per-user/doron/share/zsh/site-functions /etc/profiles/per-user/doron/share/zsh/5.7.1/functions /etc/profiles/per-user/doron/share/zsh/vendor-completions ~/.nix-profile/share/zsh/site-functions ~/.nix-profile/share/zsh/5.7.1/functions ~/.nix-profile/share/zsh/vendor-completions I tried putting the replacement `_todo` file in my first fpath directory - `~/.zsh/comp/tested/` but surprisingly I still got the failing devtodo completion loaded instead of the replacement completion. Assuming I'm not interested in submitting a change to ZSH's source tree, what would be the best way to handle this collision? My current rather ugly workaround is to rename the desired completion's file to `_td` and make it complete `td` instead of `todo` while using the following: td(){ todo "$@" } An alias doesn't work because ZSH see's there's such an alias and it loads devtodo's completion just like it would as if there wasn't an alias. Help will be appreciated. Doron.
Doron Behar wrote on Tue, 18 Feb 2020 18:37 +0200: > I tried putting the replacement `_todo` file in my first fpath directory > - `~/.zsh/comp/tested/` but surprisingly I still got the failing devtodo > completion loaded instead of the replacement completion. Hmm, interesting question. «autoload» prefers the first match of a given /function name/, but it's possible that compsys prefers the /last/ directory for determining the command-name-to-function-name mappings? In which case, putting your _todo in the last directory might help? (But read on) > Assuming I'm not interested in submitting a change to ZSH's source tree, > what would be the best way to handle this collision? Run «compdef _todo todo» after compinit. Cheers, Daniel
On Tue, 2020-02-18 at 18:37 +0200, Doron Behar wrote:
> I tried putting the replacement `_todo` file in my first fpath directory
> - `~/.zsh/comp/tested/` but surprisingly I still got the failing devtodo
> completion loaded instead of the replacement completion.
The files have different names, so they're both loaded. To get the
first file to be loaded used by compdef, remove the ~/.zcompdump*
file --- exact names vary depending on configuration but it's safe to
remove any you find --- and it will be regenerated with the correct
configuration next time you start the shell.
(You can easily confirm this is the issue by finding the wrong
association in the existing dump file.)
pws
On Tue, Feb 18, 2020 at 04:50:19PM +0000, Daniel Shahaf wrote: > Hmm, interesting question. «autoload» prefers the first match of a > given /function name/, but it's possible that compsys prefers the > /last/ directory for determining the command-name-to-function-name > mappings? In which case, putting your _todo in the last directory > might help? (But read on) Didn't help. > > > Assuming I'm not interested in submitting a change to ZSH's source tree, > > what would be the best way to handle this collision? > > Run «compdef _todo todo» after compinit. That helped. Thanks! Regards, Doron.
On Tue, Feb 18, 2020 at 05:02:20PM +0000, Peter Stephenson wrote:
> The files have different names, so they're both loaded. To get the
> first file to be loaded used by compdef, remove the ~/.zcompdump* file
> --- exact names vary depending on configuration but it's safe to
> remove any you find --- and it will be regenerated with the correct
> configuration next time you start the shell.
If I remove the ~/.zcompdump* files and don't ran the `compdef` command,
the same issue occurs.
Doron.
On Tue, 2020-02-18 at 21:17 +0200, Doron Behar wrote:
> On Tue, Feb 18, 2020 at 05:02:20PM +0000, Peter Stephenson wrote:
> >
> > The files have different names, so they're both loaded. To get the
> > first file to be loaded used by compdef, remove the ~/.zcompdump* file
> > --- exact names vary depending on configuration but it's safe to
> > remove any you find --- and it will be regenerated with the correct
> > configuration next time you start the shell.
> If I remove the ~/.zcompdump* files and don't ran the `compdef` command,
> the same issue occurs.
That suggests something unusual in your set up as the compinit script
handles this case by design. For example,
- fpath is being modified after compinit;
- something is using "compdef" explicitly for the wrong function.
Obviously, those are just random guesses. You can get a bit further
by looking in the appropriate .zcompdump file. If it's showing
the wrong function, that suggests the fpath was not set up
correctly at the point compinit was run. If it's showing
the right function, something monkeyed with the definition later.
If you care enough, you could instrument compdef to print a message
when it handles one of the two functions.
However, your workaround of using compdef by hand will be fine.
pws