| Recommender questions [message #805631] |
Fri, 24 February 2012 00:59  |
|
Hi, thanks for this very promising tool.
I have some usability questions.
First if I enter code like this
xxx.setDisplay(parent.) and type CTRL+SPACE it offers me a getFont() method. This method only can accept a Display object so why would it offer me getFont()?
Here is an image explaining: http://screencast.com/t/1zM0FSeY
Then, If i do code completion and type stuff like
IEditorInput p;
p.CTRL-SPACEgetr
it still persists in showing getAdapter as first in the list when I wanted to do getResource.
Here is an image to explain what I mean: http://screencast.com/t/gaiUP7FJYxIw
Thanks!
Wim
[Updated on: Fri, 24 February 2012 01:00] Report message to a moderator |
|
|
|
| Re: Recommender questions [message #807656 is a reply to message #805631] |
Sun, 26 February 2012 21:05  |
|
Ok so this should not happen. I will gather some info for you.
And what about the second question?
If i do code completion and type stuff like
IEditorInput p;
p.CTRL-SPACEgetr
it still persists in showing getAdapter as first in the list when I wanted to do getResource.
Here is an image to explain what I mean: http://screencast.com/t/gaiUP7FJYxIw
Thanks,
Wim
|
|
|
| Re: Recommender questions [message #807696 is a reply to message #805631] |
Sun, 26 February 2012 22:35 |
|
Hi Wim,
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.
Best,
Marcel
|
|
|
| Re: Recommender questions [message #807702 is a reply to message #807656] |
Sun, 26 February 2012 22:47 |
|
Hi Wim,
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.
Thanks,
Marcel
[Updated on: Sun, 26 February 2012 22:49] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02654 seconds
] 
Search
Help
Register
Login
Home
