Feature idea
During auto-completion of 3rd party tools we should support synonyms such -T or --threads for mvn or mvnd.
This is already prepared with #2129 but not yet implemented functionally (I already set ready-to-implement but the work of this issue should be based on #2129 that is hopefully merged by then).
Therefore, this story is about supporting synonyms in the AutoCompletionRegistry.
Acceptance Criteria:
As a result if I do completion on ide mvn -T 1C -[tab] I should not any more get -T or --threads suggested because it does not make sense to have the same option twice.
Details:
Therefore, instead of having the candidates as a String create an class CompletionEntry containing the String and delegate the logic that is currently implemented in AutoCompletionRegistry inside the for loop to a complete method of CompletionEntry.
Then we can have multiple sub-classes of CompletionEntry with specific features.
The first thing is to add a List<String> synonyms the CompletionEntry so the acceptance criteria can be made working.
Additional context
Maybe CompletionCandidate could also become and interface that is also implemented by CompletionEntry so we can directly use it as such, but that is currently just an idea to be challenged.
Feature idea
During auto-completion of 3rd party tools we should support synonyms such
-Tor--threadsformvnormvnd.This is already prepared with #2129 but not yet implemented functionally (I already set
ready-to-implementbut the work of this issue should be based on #2129 that is hopefully merged by then).Therefore, this story is about supporting synonyms in the
AutoCompletionRegistry.Acceptance Criteria:
As a result if I do completion on
ide mvn -T 1C -[tab]I should not any more get-Tor--threadssuggested because it does not make sense to have the same option twice.Details:
Therefore, instead of having the candidates as a
Stringcreate an classCompletionEntrycontaining theStringand delegate the logic that is currently implemented inAutoCompletionRegistryinside theforloop to acompletemethod ofCompletionEntry.Then we can have multiple sub-classes of
CompletionEntrywith specific features.The first thing is to add a
List<String> synonymstheCompletionEntryso the acceptance criteria can be made working.Additional context
Maybe
CompletionCandidatecould also become and interface that is also implemented byCompletionEntryso we can directly use it as such, but that is currently just an idea to be challenged.