zsh-users
 help / color / Atom feed
* 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: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 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 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, back to index

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

zsh-users

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-users

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git