Completion: access to whole input?

[windsource]

When using dynamic completion I have access to the currently typed argument in the custom completer passed to ArgValueCompleter::new.

Would it possible to also get access to the other arguments, that have been entered already? This would help to get dynamic completions in some cases?

Example:

mycmd -a -b somestart + <TAB>

would also provide access to -a -b which can be used to complete somestart.

[epage]

Support for context-aware completions is something we are intentionally holding off on at the moment. Our primary goals are (1) feature parity with the static completions and (2) feature parity with Cargo's completions (our test client for this feature).

This will take a bit of design work. We don't want to expose the literal argv and have people manually re-parse things as that is brittle to get the right policies. Currently ArgMatches isn't design for reuse by this. We'd either need to define a new type or stabilize more ArgMatches behavior.

[AskeyNil]

When will this design work be carried out?

[epage]

There is no clear timeline for this. Our priorities are on parity with clap_complete and parity with Cargo's hand written completions. There are more features after that that will likely have a larger impact before we get to contextual parsing like that.

[FFY00]

@epage, what are the current design constraints with ArgMatches? The issue I noticed was it not being ready to return errors, which would be needed if we try to request a missing argument. That could be solved via an intermediate with that functionality, and which ArgMatches could then extend, swallowing the errors. What else am I missing?

[epage]

ArgMatches has no-panic variants of each function.

ArgMatches has no public constructor and clap_complete is a different crate.

[AskeyNil]

I currently use multiple command line parsing to try to bypass the context-free association

[iesahin]

I'm writing completions for xvc and I hit this issue as well.

Fox example, Xvc has commands like xvc pipeline -p preprocessing step -s load and options for -s are specific to the name given in -p.

For an option definition like,

    #[arg(
        long,
        add = ArgValueCompleter::new(completions::step_name_completer))]
    pub step_name: Option<String>,

It would be very easy to get this if it were possible to pass a context argument to step_name_completer that contains the partially parsed set of options. I see that partial is a design challenge and you don't want to expose argv but even a set of Vec<HashMap<String, [String]>> as the context may go a long way. It could contain something like [{"xvc": []}, {"pipeline": []}, {"--pipeline-name": ["preprocessing"]}, {"--step-name": []}] for the above example and the user can do whatever they want to do with this.