Case-insensitive LookupElements mess with the lookup string
The languages in my custom language plugin are case-insensitive. I'd like to make the completion LookupElements case-insensitive, but this has a quite strange side-effect on the inserted strings. For example, if the project has a type named CamelCasedType and types "camel", I create a LookupElement with lookup string "CamelCasedType". If I then call withCaseSensitivity(false), LookupImpl.getCaseCorrectedLookupString() changes the lookup string to "camelcasedtype". Similarly if the user types "CCT" and accepts this completion, "CAMELCASEDTYPE" is inserted.
What I want is the behavior that occurs when the entire IDE is set to case-insensitive completion where both "camel" and "CCT" would result in the proper lookup string of "CamelCasedType" as specified by my plugin, but I don't want the user to have to change that global setting. Many users (myself included) also work in case-sensitive languages such as Java and that setting has a broad effect.
Is there some way to make specific completions case-insensitive and have them behave the way they would if the entire IDE was configured for case-insensitive completions rather than how the do when LookupElement.isCaseSensitive() is false?
Please sign in to leave a comment.
You can make your lookup elements case-sensitive again, and substitute prefix matcher (CompletionResultSet#withPrefixMatcher) with one that doesn't care about case. This should achieve the effect you want. You can also do some additional case correction in the lookup element's insert handler.
However, a pull request that'd fix your cases for all case-insensitive lookup items in all languages would be also nice to have :)
Thanks, Peter. I feel kind of silly that I didn't think about registering a custom prefix matcher for these completion providers/contributors. Makes total sense! As for insert handlers, I may pretty extensive use of them today for a variety of reasons, and it makes sense that I could use one if I set the lookup element to case-insensitive, but it just seems like it would be undoing something that I'd prefer wasn't being done to start. I'll look into the prefix matcher option since everything else works as expected as long as the prefix match is case-insensitive.