Maintainer's notes:
Remaining work for feature parity
Non-blocking work
Design considerations
- Make it easy to use for the natively supported shells but allow other shells to be supported
Prior art
#3022 was a tipping point for me in realizing that maybe our current approach to completions doesn't work. We effectively have to implement a mostly-untested parser within each shell. Examples of other problems that seem to stem from this:
If we take the approach of argcomplete where we do the parsing in our core code, rather than in each completion script, this will help us share parsing logic between shell, share some or all parsing logic with clap itself, and make a subset of the logic more testable.
We also need to decide whether to morph the existing parser into supporting this or create a custom parser (since the needs are pretty special). If we do a custom parser, we should probably do #2915 first so we can reuse lexing logic between clap and the completion generation. I've also been considering #2912 which would allow reusing the completion logic with any CLI parser.
Maintainer's notes:
Remaining work for feature parity
ValueHints (feat(complete): Skeleton for Rust-driven completions #3656)OsStringto preserve non-UTF8 pathsstdoutshould not be used before getting to completion processing in case the completions are requested (docs(complete): Expand dynamic docs #5643)clap_complete::env::Elvishgenerates code deprecated in 0.18, removed in 0.21 #5729Non-blocking work
is_require_equal_setsupport (Supportis_require_equal_setin native completions #3923)lastsupporttrailing_var_argsupportValueHintsDesign considerations
Prior art
#3022 was a tipping point for me in realizing that maybe our current approach to completions doesn't work. We effectively have to implement a mostly-untested parser within each shell. Examples of other problems that seem to stem from this:
If we take the approach of argcomplete where we do the parsing in our core code, rather than in each completion script, this will help us share parsing logic between shell, share some or all parsing logic with clap itself, and make a subset of the logic more testable.
We also need to decide whether to morph the existing parser into supporting this or create a custom parser (since the needs are pretty special). If we do a custom parser, we should probably do #2915 first so we can reuse lexing logic between clap and the completion generation. I've also been considering #2912 which would allow reusing the completion logic with any CLI parser.