* Having a hard time dealing with a completion collision @ 2020-02-18 16:37 ` Doron Behar 2020-02-18 16:50 ` Daniel Shahaf 2020-02-18 17:02 ` Peter Stephenson 0 siblings, 2 replies; 6+ messages in thread From: Doron Behar @ 2020-02-18 16:37 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Having a hard time dealing with a completion collision 2020-02-18 16:37 ` Having a hard time dealing with a completion collision Doron Behar @ 2020-02-18 16:50 ` Daniel Shahaf 2020-02-18 19:13 ` Doron Behar 2020-02-18 17:02 ` Peter Stephenson 1 sibling, 1 reply; 6+ messages in thread From: Daniel Shahaf @ 2020-02-18 16:50 UTC (permalink / raw) To: Doron Behar; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Having a hard time dealing with a completion collision 2020-02-18 16:50 ` Daniel Shahaf @ 2020-02-18 19:13 ` Doron Behar 0 siblings, 0 replies; 6+ messages in thread From: Doron Behar @ 2020-02-18 19:13 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Having a hard time dealing with a completion collision 2020-02-18 16:37 ` Having a hard time dealing with a completion collision Doron Behar 2020-02-18 16:50 ` Daniel Shahaf @ 2020-02-18 17:02 ` Peter Stephenson 2020-02-18 19:17 ` Doron Behar 1 sibling, 1 reply; 6+ messages in thread From: Peter Stephenson @ 2020-02-18 17:02 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Having a hard time dealing with a completion collision 2020-02-18 17:02 ` Peter Stephenson @ 2020-02-18 19:17 ` Doron Behar 2020-02-19 9:35 ` Peter Stephenson 0 siblings, 1 reply; 6+ messages in thread From: Doron Behar @ 2020-02-18 19:17 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Having a hard time dealing with a completion collision 2020-02-18 19:17 ` Doron Behar @ 2020-02-19 9:35 ` Peter Stephenson 0 siblings, 0 replies; 6+ messages in thread From: Peter Stephenson @ 2020-02-19 9:35 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-19 9:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20200218163908eucas1p28a3b95a5e11163f515ee6e902ff9bbf5@eucas1p2.samsung.com> 2020-02-18 16:37 ` Having a hard time dealing with a completion collision Doron Behar 2020-02-18 16:50 ` Daniel Shahaf 2020-02-18 19:13 ` Doron Behar 2020-02-18 17:02 ` Peter Stephenson 2020-02-18 19:17 ` Doron Behar 2020-02-19 9:35 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).