-
Notifications
You must be signed in to change notification settings - Fork 400
-
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):
# gh(1) (GitHub CLI) completion -*- shell-script -*- # This serves as a fallback in case the completion is not installed otherwise. _comp_cmd_gh__ifs=$IFS IFS=$' \t\n' _comp_cmd_gh__reset_shopt=$(shopt -po posix) set +o posix . <("1ドル" completion --shell bash 2>/dev/null) $_comp_cmd_gh__reset_shopt IFS=$_comp_cmd_gh__ifs unset -v _comp_cmd_gh__ifs _comp_cmd_gh__reset_shopt [[ -n $(complete -p "1ドル" "${1##*/}" 2>/dev/null) ]] # ex: filetype=sh
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
Replies: 1 comment 1 reply
-
but I wanted to bounce the overall idea first for some feedback. So... thoughts?
I agree with the overall idea.
A downside is that we need to ensure non-POSIX mode, which gets a bit messy.
If the non-POSIX mode is for the process substitution, I think we can instead use eval -- "$("1ドル" completion --shell bash 2>/dev/null)" here, (where I assumed that the completion definitions generated by "1ドル" completion --shell bash do not rely on the non-POSIX mode).
I think it is safer to do local IFS=$' \t\n' assuming that the completion file will be sourced from inside __load_completion. Or we can declare local IFS=$' \t\n' in __load_completion. Then, we don't have to worry about the case that the loading is canceled by C-c and that the modified IFS remains.
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.
Instead of [[ -n $(...) ]], I would use complete -p "1ドル" &>/dev/null || complete -p "${1##*/}" &>/dev/null to avoid a fork.
Don't know if there's something additional we should be doing in snippets like this.
__load_completion seems to include the adjustment of 1ドル beginning with a backslash \. Maybe we can directly reference $cmd here, or we can replace 1ドル by specifying the argument "$cmd" in sourcing the completion file here (i.e., . "$compfile" "$cmd").
Anyway, we can discuss the implementation and see if we could extract the boilerplate into a helper function etc in a PR,
I guess the suggested example of _gh is already universal for all the commands that accept the arguments of the form "$cmd" completion --shell bash, so maybe we can put the files for the respective completion generators, completions/{_cobra,_argcomplete,_clap_complete}, and symlink each completions/_{cmd} to one of them.
Beta Was this translation helpful? Give feedback.
All reactions
-
Thanks for your feedback! Opened #905 for this.
Maybe better to continue discussion on the implementation details in the PR, but just dropping a note here for a few things I adopted already: localized IFS in __load_completion (and the posix mode resetter in the sourced file), made use of the symlinking, avoided the fork at end. I opted to use one of the actual commands as the "main" one instead of the _cobra etc "library" suggestions, in order to avoid them being source for hypothetical commands named cobra etc.
Beta Was this translation helpful? Give feedback.