Open stecman opened 9 years ago
In other words we want to allow commands to register own completion handlers.
Would we require command name in the handlers registered that way to match current command name? What I'm afraid of is that somebody can register auto-complete in command A for command B and wonder why it doesn't work.
Won't it be too confusing for users whose commands implement both interfaces to decide in which method to put completions?
Approach with handler registration is better in the way, that it allows to proxied completion handlers to be registred, that will only calculate their completions when handler is invoked. However with a bunch of IF statements same can be done in completeOptionsValues/completeArgumentValues
methods as well.
Currently,
CompletionAwareInterface
can't cleanly useCompletionInterface
implementations. (eg. deferring path completion to the shell withShellPathCompletion
). A simple solution might be another interface that exposesCompletionHandler
to commands:In saying that, this makes me think that the responsibility for completion configuration (command name, argument/option, name) shouldn't really belong to
CompletionInterface
. It was a convenience when the code was originally created to have the API like that, but it doesn't entirely make sense and it means that completions require information they don't actually need to run.