Problem
cook has 14 subcommands (recipe, server, build, shopping-list, seed, search, import, report, doctor, pantry, lsp, login, logout, update), each with its own flags, but there is no shell completion. Users have to remember command names and flags or keep cook --help open.
Proposal
Add a cook completions <shell> subcommand that prints a completion script to stdout, using clap_complete — the CLI already uses clap 4.5 with the derive API, so generation is essentially free from the existing CliArgs.
cook completions bash > /usr/local/etc/bash_completion.d/cook
cook completions zsh > "${fpath[1]}/_cook"
cook completions fish > ~/.config/fish/completions/cook.fish
cook completions powershell
cook completions elvish
Scope
- New
src/completions.rs with CompletionsArgs { shell: clap_complete::Shell } and a run() that calls clap_complete::generate against CliArgs::command().
- New
Command::Completions variant in src/args.rs + match arm in main.rs.
- Docs page under
docs/ describing per-shell install (kept in sync with cooklang.org via the usual one-directional flow).
Open questions
- Feature-gated subcommands.
import, server, lsp and update are behind cargo features. Generation happens off the runtime Command, so a completion script generated by a given binary will match that binary's features — worth calling out in the docs rather than working around.
- Dynamic completion of recipe names. Completing
.cook files (and recipe.cook:2 scaling suffixes) for cook recipe / cook shopping-list would be the real quality-of-life win. clap_complete::engine supports dynamic completion, but it is a bigger change and could land as a follow-up. Suggest shipping the static version first.
- Shipping the scripts. Release archives (
cook-*.tar.gz / .zip) currently contain just the binary. Should the build generate and bundle completion scripts so packagers (Homebrew et al.) can install them automatically?
Prior art
gh, rustup, cargo, starship all expose the same <tool> completions <shell> shape; clap_complete is the standard route for clap-based CLIs.
Problem
cookhas 14 subcommands (recipe,server,build,shopping-list,seed,search,import,report,doctor,pantry,lsp,login,logout,update), each with its own flags, but there is no shell completion. Users have to remember command names and flags or keepcook --helpopen.Proposal
Add a
cook completions <shell>subcommand that prints a completion script to stdout, usingclap_complete— the CLI already uses clap 4.5 with the derive API, so generation is essentially free from the existingCliArgs.Scope
src/completions.rswithCompletionsArgs { shell: clap_complete::Shell }and arun()that callsclap_complete::generateagainstCliArgs::command().Command::Completionsvariant insrc/args.rs+ match arm inmain.rs.docs/describing per-shell install (kept in sync with cooklang.org via the usual one-directional flow).Open questions
import,server,lspandupdateare behind cargo features. Generation happens off the runtimeCommand, so a completion script generated by a given binary will match that binary's features — worth calling out in the docs rather than working around..cookfiles (andrecipe.cook:2scaling suffixes) forcook recipe/cook shopping-listwould be the real quality-of-life win.clap_complete::enginesupports dynamic completion, but it is a bigger change and could land as a follow-up. Suggest shipping the static version first.cook-*.tar.gz/.zip) currently contain just the binary. Should the build generate and bundle completion scripts so packagers (Homebrew et al.) can install them automatically?Prior art
gh,rustup,cargo,starshipall expose the same<tool> completions <shell>shape;clap_completeis the standard route for clap-based CLIs.