Community
Participate
Working Groups
Created attachment 141779 [details] first screenshot Build ID: M20090211-1700 Steps To Reproduce: I created three classes: MyFirstCarConverterTest MySecondCarConverterTest MyFifthCarConverterTest. Select Open Type. Search for MFCCT. MyFirstCarConverterTest and MyFifthCarConverterTest appear. (See first screenshot) Next search for My*Test. All three classes appear. (See second screenshot) Third, MyFCCTest also returns the classes named First and Fifth. (third screenshot.) Now let's try to add wildcards with camel casing. M*CCT returns nothing (fourth screenshot), neither does My*CCTest (fifth screenshot.) Is that a hard thing to do? More information:
Created attachment 141780 [details] second screenshot
Created attachment 141781 [details] third screenshot
Created attachment 141782 [details] fourth screenshot
Created attachment 141783 [details] fifth screenshot
Hey, I just ran into this too. Seems to be in more than just the Open Type dialog. I intially found it in the "Add Java Exception Breakpoint" dialog. The filter is prepopulated with "*Exception*" and I entered "NP" at the very beinging and was very suprised not to see NullPointerException in the listing. Hope this one gets addressed soon.
I see what you mean, but this was really designed to be either camel case or wildcards, but not both together. Wildcards have always been case insensitive in these dialogs. This needs to stay at least when the whole pattern is lowercase. To add camel case support to wildcards, org.eclipse.jdt.core.search.SearchPattern and references to it in the search engine would have to be updated. In particular, they would have to allow combining R_PATTERN_MATCH with R_CAMELCASE_MATCH. SearchPattern#validateMatchRule(String, int) would have to accept both rules iff the stringPattern contains a wildcard and at least one uppercase character, but must continue to return just R_PATTERN_MATCH if the string contains only lowercase characters, wildcards, and '.'.
> Is that a hard thing to do? It's not trivial, since search APIs are involved (I filed bug 284990 for JDT/Core), and already the implementation details of simple camelCase matching are quite involved.
