generate shell completion from specs

[millettjon]

I'm curious how hard this would be.
Maybe have a special flag --complete that takes a partial command line and returns the list of completions to the shell.

[borkdude]

Feel free to experiment. I'm open to this, but I think completions are shell (bash, zsh, fish, etc) specific?

[millettjon]

Cool.

zsh apparently has a bash compatibility mode. I'm not sure about fish.

My inspiration for this is the compleat tool which does something similar and works with bash, zsh, and fish.

[teodorlu]

Idea for API:

(babashka.cli/complete {:shell :zsh :dispatch-table dispatch-table})

Then the user can choose to map --complete or complete or something else at their own leisure :)

Unknowns / uncertainty: I have only ever used babashka.cli/dispatch for my use. Not all CLIs are built around a dispatch table. I suppose a general solution would be better.

[bobisageek]

There was a discussion on slack that was I semi-sidetracked into this area. I wanted to mention carapace as sort of a player in the shell completion space. It's a little bit like the aforementioned compleat in that it takes a 'spec' and can do completions, but it's different in that it's a separate program that acts as sort of a 'completion engine' for a bunch of different shells. In somewhat Clojurian parlance, you could argue that it aims to decomplect completion specs from shell-specific impls by using only enough of each shell's completion plumbing to get the shell to call it for the candidate completions.

This comes with a cost, i.e. users of the completion need to be using carapace to get the niceities, but especially the commands that are 'first-party' in carapace have some nice touches (got an alias that expands to 'git checkout'? carapace will complete that with the branch names of the repo you're working in). From the digging around that I've done into carapace, I don't see a way to use it for generating "shell-native" completions. I'd say it doesn't really want to do that, because then it's somewhat limited by what each shell offers.

It does look like the authors have given these ideas some thought, and even written some (short) prose about various approaches, including generators and rolling the completion into the app itself: https://pixi.carapace.sh/porcelainShop.html.

I wonder if (and I'm just spitballing here) a good fit for bb.cli might be generating specs that can be fed to things like compleat or carapace, or other tools that are completion-centric. It feels like it could be somewhat of a multiplier, in that if compleat (or another app that used a similar input format) started supporting elvish or powershell or xonsh tomorrow, then being able to generate that spec provides an ability to make those completions without bb.cli having to know how to do it. It doesn't need to be to the exclusion of generating shell-specific ones, but part of me thinks "if someone else has already drudged through the morass of compgen and compinit and whatever, or if there's one person on the powershell team who isn't going to contribute to bb.cli, but is a completion fanatic and loves turning yaml into powershell completion, can we leverage those?".

Or, alternately, is there a case for making a compleat-type thing that's separate from bb.cli, that isn't behind the metaphorical wall of using bb.cli. For example, bb itself doesn't use bb.cli, so although we'd have (at least somewhat) the data to generate completions, we couldn't. I guess in the bigger picture I'm wondering if the hypthetical (defn spec->completion [spec shell]) function maybe has more value if spec is datafied and/or external.