Community
Participate
Working Groups
for OpenTypeDialog and ContentAssist, it would be good if we could search for bindings case-insensitively. To achieve this I'd like to order bindings case-insensitively, and then within a case-insensitive equivalence group, order case-sensitively. i.e. for Java Strings this would be: Comparator<String> c = new Comparator<String>() { public int compare(String o1, String o2) { String s1 = (String) o1; String s2 = (String) o2; int cmp= s1.compareToIgnoreCase(s2); if(cmp==0) { cmp= s1.compareTo(s2); } return cmp; } }; This way we retain the ability to look-up bindings case-sensitively, but also gain the ability to look-up case-insensitively when needed. For now, I'd only propose changing the IIndex.findBindingsForPrefix method to be optionally case-insensitive
(In reply to comment #0) Yes, that's the way to organize the BTree, although its probably worth to make the comparison more efficient, we'll see. We also had a discussion on this in bug 169860.
Created attachment 59661 [details] proposed patch this patch implements the above approach. Some more notes * PDOMFile comparison is unaffected (still case-sensitive) * The case-sensitivity comparison is done at the db level in ShortString. It only remaps a-z and A-Z on to each other. * I re-ordered a pair of expected results in a test (ContentAssistTests.testBug72824) to make it pass again under the new scheme. I'd like to commit this today if no-one objects
Created attachment 59681 [details] patch applied to HEAD this is the same as the previous patch, but reattaches DBTest to the test suite as it was missing
marking as FIXED
Oops looks like I was too slow typing in this comment and the bug has been fixed in the process... Anyway, I just had one concern regarding PDOMCPPNamespace.find(String name, boolean prefixLookup). The visitor created in this method is set to always be case sensitive. For content assist at least, case-sensitivity would need to depend on whether or not it is a prefix lookup. So passing '!prefixLookup' instead of 'true' to the visitor's contructor would work for content assist, or else another boolean parameter for the find(...) method would be needed. In fact, are there any situations in which we need to control case-sensitivity independently of whether or not a prefix lookup is taking place? If this is the case then it might be wise to remove any 'caseSensitive' booleans and simply make case-sensitivity depend on the 'prefixLookup' booleans which already existed.
hi Bryan, sorry - I'm beginning to feel the heat a little and needed to move onwards ;) I'll re-open 109724 as that bug tracks content assist specifically. thanks, Andrew
