Repository navigation
AbstractCompletionProvider#getCompletionByInputText does not find completion #49
Description
The problem is AbstractCompletionProvider holds completion sorted ascending in natural order but getCompletionByInputText method does search in case insensitive mode.
The workaround for descendant providers is to sort completions in case insensitive mode before getCompletionByInputText call and after turn previous sorted order back.
The similar situation could be obesrved to getCompletionsImpl method.
Activity
tttwang23 commentedon Jun 29, 2018
All true. Lists sorted case insensitively have ill defined ordering and they are incompatible with binary tree optimizations. For example, a SortedMap with case insensitive ordering has bugs. In my app I work around these issues by requiring lists I auto-complete to be sorted by unique case insensitive ordering. If two target strings are equal case insensitively, then return the case sensitive order - uniqueness property preserved.
Look at my proposed pull request where you have two AbstractCompletions. One completion has "aaa" as the string representation, while the other one has "AAA" as the string representation. Should the compareTo() method return 0 for this case? No, of course not. It would ruin the natural ordering requirement.
Natural ordering means that if compareTo(a,b) is less than 0, then compareTo(b,a) is greater than 0. If compareTo(a,b) is 0, then a and b are the same. Note "aaa" is not the same as "AAA".
tttwang23 commentedon Jun 30, 2018
Pull request 36 might solve your issue. The current default compareTo(a,b) in AbstractCompletion violates natural ordering; so that need to be fixed first.