kislyuk / argcomplete

Python and tab completion, better together.
https://kislyuk.github.io/argcomplete/
Apache License 2.0
1.39k stars 129 forks source link

zsh global completion should not be "-default-" #491

Open rpigott opened 2 weeks ago

rpigott commented 2 weeks ago

Hi.

The so called "global completion mode" for zsh implementation as a -default- completer is harmful. Setting a -default- completer is a prerogative of the user, and not any application or library (only one completer can exist per service name). The current implementation unnecessarily interferes with the user's ability to customize the zsh completion system.

Perhaps consider using #autoload instead, then applications can re-use your library code by installing their own (possibly trivial) zsh completers that invoke your function, similar to how python code might invoke your library.

llua commented 2 weeks ago

to provide a little more context, the zsh community have recently received a number of reports[0] of completion not behaving how they expect and it results from this package being pulled in, seemingly unknowingly, causing the changed behavior.

[0] https://www.zsh.org/mla/workers/2024/msg00503.html

kislyuk commented 2 weeks ago

Thanks for your interest in argcomplete.

The so called "global completion mode" for zsh implementation as a -default- completer is harmful.

Harmful to whom?

Setting a -default- completer is a prerogative of the user, and not any application or library (only one completer can exist per service name). The current implementation unnecessarily interferes with the user's ability to customize the zsh completion system.

In the context of your classification of "application or library", argcomplete is neither - it's a framework for enabling individual applications to connect to the shell to provide dynamic completions, creating a class of completers.

I agree that setting the default completer is a prerogative of the user, which is why argcomplete does not install this completer by default. If a Linux distribution installs the global completion hook by default, that's a problem to be addressed with that distribution. It should probably not be doing that, leaving that choice to the user.

Perhaps consider using #autoload instead, then applications can re-use your library code by installing their own (possibly trivial) zsh completers that invoke your function, similar to how python code might invoke your library.

I'd love to use a more specific completion hook directive, but I've searched extensively and experimented with the zsh completion engine, and nothing seems to work short of #compdef -default- (including #autoload). The only alternative that I've found to work is #compdef -P *, and that is even more invasive than #compdef -default-. By design, the argcomplete global completion hook is expected to fire for any command, regardless of name; it is not limited to specific command names.

I would love to use a more specific hook that has as few side effects as possible, and I'd love to be proven wrong about #compdef -default- being the only option; PRs are welcome. For more context, you can take a look at the discussions in this PR: https://github.com/kislyuk/argcomplete/pull/463

lilydjwg commented 2 weeks ago

I agree that this is an issue with Arch Linux. Maybe you as the project owner could communicate to the packagers more explicitly that the completion file shouldn't be enabled by default?

rpigott commented 2 weeks ago

nothing seems to work short of #compdef -default- (including #autoload).

For more context, you can take a look at the discussions in this PR: https://github.com/kislyuk/argcomplete/pull/463

I can't find any mention of #autoload in this discussion.

kislyuk commented 2 weeks ago

I agree that this is an issue with Arch Linux. Maybe you as the project owner could communicate to the packagers more explicitly that the completion file shouldn't be enabled by default?

Sure, I can do that.

kislyuk commented 2 weeks ago

@lilydjwg sorry I'm actually not going to be able to do that because I'm not going to post in that thread following the inflammatory comment by @rpigott. While @rpigott has stayed civil here in this thread, the comment in the Arch Linux gitlab issue is objectionable to me and I won't participate there. All argcomplete contributors or commenters are expected to abide by the code of conduct.

To reiterate, I support the idea of Arch not activating argcomplete global completion by default (and also pulling in the latest argcomplete release, which incorporates the fix for overly broad completer registration (fixed in 3.1.2)). Thanks for filing the issue with Arch.

lilydjwg commented 1 week ago

OK. Arch has removed the file from the package anyway (though I expected the file to be put somewhere not loaded by default, but I don't know that "somewhere").