the first one looks like a possible bug. Can you provide some more information about the context in which you are invoking code completion? To determine which methods should be proposed we use the following context informations:
- Which class is extended?
- Is the enclosing method an overriden method and if, which one?
- What methods are already called on the variable?
- How is the variable initialized (by a method return or it is a parameter for example)?
Having these details allows us to determine if it's a bug or a scenario we didn't see before in our training data.
thanks for your questions. We are glad to get early feedback on these tools.
Your second problem arises when JDT's prefix matching and Code Recommenders subwords (regex) matching collide. I assume you know how subwords is intended to work (first a regex matching for candidates matching, then a fine-tuend relevance ranking based on prefix length matching + number of matching bigrams). So, you would expect that when entered "<^space>getr", getResource should be above getAdapter since it has the longer prefix match (and even a more matching bigrams).
This kind of scoring requires JDT to recompute the relevance of its proposals after every new token and not - how it's done at the moment - once when completion was triggered. For a pure prefix matching as done by JDT this approach is sufficient but does not work well for more flexible matching such as subwords. This issue has been reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=350991 and a patch is in progress. So, you probably won't see it in 3.7 but it should work as expected in 3.8/4.2M6
For 3.7, however, the issue you described will cause a lot confusion and will never work properly since JDT does not support resorting. I'm not sure how we should handle that for 3.7. We'll probably just add a simple version that adds several redundant proposals to the bottom of the list which get filtered as soon as completion makes progress.
regarding the getDisplay issue. Could you please open a bug report? The system proposes getFont since it *had learned* that this is the most likely method to call. The fact that you actually need a display should override the relevance of getFont here. Here, our current relevance ranking system just falls too short...
The fact that is offers getFont at all is, however, correct and wanted since there might be other paths that might take you to a Display which cannot be foreseen by completion engine (yet). For example "(Display) parent.getFont().getDevice()" *may* (although unlikely) work here too. Filtering completions solely on return type would too often eliminate required proposals from the list. However, in the scenario you mentioned there should be a clear preference to getDisplay over getFont.
I think , we don't need more info than your example above to reproduce and fix the scoring system.