You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, CompletionAwareInterface can't cleanly use CompletionInterface implementations. (eg. deferring path completion to the shell with ShellPathCompletion). A simple solution might be another interface that exposes CompletionHandler 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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: