Replies: 1 comment 1 reply
-
I agree with the overall idea.
If the non-POSIX mode is for the process substitution, I think we can instead use I think it is safer to do
Instead of
I guess the suggested example of |
Beta Was this translation helpful? Give feedback.
-
Many executables these days contain builtin completion features, often so that using some command line flags, they can emit a completion function to be sourced. This is great. What tends to be lacking is automatic enablement of those completions, or even instructions how to generate and enable them. It's not unusual for the completion generator commands/options to be hidden. So installing the completions is a chore.
Some examples of libs facilitating these include cobra for Go, clap_complete for Rust, argcomplete for Python, etc.
I think it would be nice of us to provide fallbacks for generating and enabling completions for executables known to provide them. Using the backslash prefix would be good so they don't take accidental precedence.
Here's one example how such a snippet could typically look like, this one's for the GitHub CLI (
completions/_gh
):Here, we avoid writing the completion file anywhere, and instead source it on the fly. This is good, because it ensures the command and the completion file are in sync, and avoids questions related to filesystem use and placement. A downside is that we need to ensure non-POSIX mode, which gets a bit messy. Finally, we see if we got a completion installed for the invoked thing, in order for our "minimal" completion fallback to kick in if we didn't. Don't know if there's something additional we should be doing in snippets like this.
Anyway, we can discuss the implementation and see if we could extract the boilerplate into a helper function etc in a PR, but I wanted to bounce the overall idea first for some feedback. So... thoughts?
Beta Was this translation helpful? Give feedback.
All reactions