Carapace: A multi-shell completion library and binary

I tried to use this to get better completions with nushell, but it just doesn't have the breadth and depth of completions that fish has as of yet, nor does it have automatic completion generation from manages (although it does have a tool for that) so I eventually gave up and just made fish itself my nushell's completion engine. However I'll be keeping my eye on it, because it's a really cool idea to have a shared completion engine for all shells, so that everyone can pool their work, and because of course having to install two entire shells just to use one of them is a bit silly so eventually I'd like to make the switch.

Other similar projects:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;sigoden&#x2F;argc-completions">https:&#x2F;&#x2F;github.com&#x2F;sigoden&#x2F;argc-completions</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;inshellisense">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;inshellisense</a>

I tried this but couldn&#x27;t get the completions to load. I think it&#x27;s a really good idea though (much faster than zsh script completions), so hopefully soon I can retry the install and either get it working or open an issue.<p>One design aspect I do question is that completions are baked into the library. It&#x27;d be neat to have them in SQLite or something that could be updated independently (not sure how feasible that is though. I&#x27;ve never been any good at querying graphs like flag&#x2F;command completions in SQLite).

Completion for program P should be written and maintained by the &quot;owner&quot; of program P - and installed with program P. This is of course difficult when there are many different &quot;shells&quot; that each have their own &quot;language&quot; for specifying completions. A multi-shell completion library can help with this problem.<p>To me it make sense that completion for program P should be handled by program P itself. That way, completions are unlikely to get out of sync with the application, and the completion handler can use the same option parser as the application. A way to do this is to use a special &quot;hidden&quot; switch to request completion.<p>Specifically the DomTerm terminal emulator (<a href="https:&#x2F;&#x2F;domterm.org" rel="nofollow">https:&#x2F;&#x2F;domterm.org</a>) handles its own completions. Bash allows you to register a command that handles completions for some other command. The following tells bash that to handle completions for the domterm command it should call domterm with the magic &quot;#complete-for-bash&quot; option followed by the existing line and position.<p><pre><code> complete -o nospace -C &#x27;domterm &quot;#complete-for-bash&quot; &quot;$COMP_LINE&quot; &quot;$COMP_POINT&quot;&#x27; domterm </code></pre> When domterm is run with &quot;#complete-for-bash&quot; as the first argument (chosen to avoids accidental use) it processes the remaining arguments, and prints out the completion suggestions to bash.<p>I don&#x27;t know how to do something similar for other shells; suggestions welcome. Some other shells (such as Fish) include help text as part of the suggested completions. Handling that would require a more complex protocol. Perhaps one that returs a result in JSON format?<p>If a such a protocol were standardized (perhaps invoked by a &quot;#completions-as-json&quot; option?), we just need to solve a final piece of the puzzle: How does a shell know if a command understands the &quot;#completions-as-json&quot; option? My suggestion is that we define a new keyword-value pair in the &quot;desktop&quot; file specification; the shell would search for a P.desktop file,

&gt; Custom completions can be defined using yaml files.<p>The concept is awesome but it&#x27;s curious to see YAML at the core of this project, rather than a Turing-complete, embeddable language like Lua.

Reminds of of Project Hail Mary. Never heard the word &quot;carapace&quot; before that book...