Delegate completions for a specific argument to the completions of an external program
alerque opened this issue · comments
Please complete the following tasks
- I have searched the discussions
- I have searched the open and rejected issues
Clap Version
4.5
Describe your use case
I have an app that has several subcommands, some of which are wrappers around other CLI tools. For example casile
has several subcommands, but one of them is casile make
that sets up a special environment and this passes all the remaining args to make
. I have it setup something like this:
#[derive(Subcommand)]
pub enum Commands {
Make {
target: Vec<String>,
},
}
The Vec<String>
seems to be the best way to collect further arguments and pass them through to the subprocess. Since passing other flags to make
is valid here the arguments beyond this point may or may not be filenames, and even if they are they may or may not exist yet which makes filename completion (as I would get if I made this a Vec<PathBuf>
or similar not very useful.
Describe the solution you'd like
I'd like to be able to specify something in the CLI that specifically called out the command for which to use completions for:
#[derive(Subcommand)]
pub enum Commands {
Make {
#[clap_complete(delegate="make")]
target: Vec<String>,
},
}
I don't know what the exact ergonomics should be, but somehow I'd like the final generated completion scripts to delegate completions for arguments in this position to the completion script of a different external command.
Alternatives, if applicable
No response
Additional Context
I'm not sure all supported shells have a way to handle this, but at least bash and zsh do.
I looked at that issue before opening this, but don't think it's related. Implementing this does not require dynamic completion support. Delegating to the completions of another command is not at all the same thing as using the output of a command as completions, and the plumbing needed to make shells do this is different (and simpler).
We plan to completely change our completion system, see #3166.
Doing major re-work of our existing completions to fit this is a bit of a dead end and could put us in a design bind for when we get to the end state of #3166.
#3166 is also responsible for us tracking being able to add more dynamic completion state to arguments, like your proposed delegate
attribute.