Community
Participate
Working Groups
It would be very useful to search within the list of code completions using wildcards. A typical use case would be the completion list of methods that can be called on an object. These lists can be quite long and sometimes it is not clear if the name of a boolean getter is prefixed with "is" or "are" or nothing. A wildcard search using * would be helpful.
Moving to JDT Core for comments/investigation.
What do you suggest exactly ? Use wildcards directly in the editor? eg. class X { void getXMethod(){} void getYMethod(){} void getXFoo(){} void foo (X x) { get*Method| // do ctrl+space at | } } //then getXMethod and getYMethod are proposed Or do ctrl+space and then type wildcards to filter proposed proposals ? eg. class X { void getXMethod(){} void getYMethod(){} void getXFoo(){} void foo (X x) { get| // do ctrl+space at | } } //then getXMethod, getYMethod and getXFoo are proposed. You type '*Method' and getXFoo is removed from the list of proposal. The first possible behavior should be added in JDT Core but would be very hard to add Wildcard characters like * already means something in the java grammar. So in 'get*Method' * can be a multiply or a wildcard if the code is inside a method and is a syntax error outside a method. Add this behavior would require to modify deeply our completion parser. So we won't add this kind of behavior for 3.3 and it won't be easy to add it in a future version. The second possible behavior should be added in JDT Text and i don't know if it easier to implements. Daniel, what do you think about this second possibility ?
Thank you for the quick feedback! I was thinking about the second use case, I would even popup the completion list on the object without any prefix sometimes and then use *Method to see all the methods that contain Method. A good example would be the class "Class" that has: getEnclosingMethod getDeclaredMethod getDeclaredMehtods and more. Similar behavior as in the dialog you trigger with Ctrl-o. Thanks, Felix
Moving to JDT Text
*** Bug 448296 has been marked as a duplicate of this bug. ***