fermyon
Shell completions
This is a second crack at command completions. It doesn't use the clap_complete module because that didn't do a great job; instead, it uses custom code which, well, I don't know if it does a great job either, but it is a bit smarter at least. For example:
- Only file parameters are completed with file names
spin upand friends get completions for their forwarded arguments (e.g. trigger args)spin newandspin addare completed with a list of installed templatesspin plugincommands are completed with lists of installed or known plugins as appropriate
The way this works is:
- Building Spin now builds an additional executable,
_spin_completions - In Bash, you run
complete -C </path/to/_spin_completions> spinto install the completions- This is only for the current shell session so you need to add it to your profile or bashrc
- Get completin'
Obviously we would want to put a bit more user experience around that!
Known issues:
- At the moment it always uses the HTTP trigger to suggest completions for
spin upand related stuff. [Fixable.] - The code is kinda gnarly. [Probably fixable though I'm already scared of it so we are off to a flying start.]
- It is Bash only, so we would still need solutions for zsh and fish. [Probably not fixable.] (I am struggling to understand their docs but they may rely on completions being written in the shell language? although that seems unlikely. In theory we could implement the
Completioninputtrait for other shells but not sure if we have the knowledge or time.)
Could we use clap_complete and amend it by hand?
We could. clap complete spits out a big ball o' shell script - we could capture that and fix it up manually. This would likely mean we had to manually maintain the completions in shell - it would be hard to capture the changes in a way that we could re-apply after a Spin CLI change. But it would take someone shellier than me - I had a crack at the bash one with no joy. I think it would take a substantial refactor, but after that maybe it would be okay?
Could we implement the CompletionInput trait for zsh and fish, and get them that way?
I don't know how hard it would be. It's a bit of a diversion and (the upstream shell_completion repo is pretty idle.)[https://github.com/joshmcguigan/shell_completion] so I dunno if they would find a home upstream. In principle the core engine should work fine with other shells though.
Anyway here we are and I throw myself on the mercy of the court
I haven't found any documents indicating that zsh or fish completions can be written in anything other than ~shell script~ their custom languages, so this approach may be a dead end for those shells.
I haven't found any documents indicating that zsh or fish completions can be written in anything other than ~shell script~ their custom languages, so this approach may be a dead end for those shells.
zsh does have bash completion compat via bashcompinit but my vague understanding is that it is somehow less-good than native zsh completion :shrug:
Works in Bash, although it seems en expensive route without zsh and Fish support. Seems like this is harder than expected.
This is back on the want list for Spin 2.1. What's the best way to figure out a path to delivery? cc @mikkelhegn @melissaklein24
My observation, based on the information in this PR is that what's left is a decision about how to implement it. I have no qualified opinion on that. Prioritizing requirements, I think the shells we should support (in priority), would be zsh, bash and fish.
If zsh is highest priority, then the approach here won't work. That puts us back to clap_complete, which gives us subcommand names and options, but only offers files for values (e.g. spin new -t <TAB> would pop a list of files rather than a list of templates). Maybe that's the "better than nothing" option...?
If we do that, I might maybe see if I can ship the "better" bash completions as a Spin plugin, for those as want them.
Sounds like a plan, maybe getting the first version out there inspires improvements to either of the approaches.