Eclipse Community Forums: Code Recommenders

Home » Archived » Code Recommenders » Recommender questions

Thu, 23 February 2012 19:59

Eclipse User

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: Thu, 23 February 2012 20:00] by Moderator

Re: Recommender questions [message #805947 is a reply to message #805631]

Fri, 24 February 2012 05:27

Eclipse User

Hi,

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 reporting!
Johannes

Re: Recommender questions [message #807656 is a reply to message #805631]

Sun, 26 February 2012 16:05

Eclipse User

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 17:35

Eclipse User

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 17:47

Eclipse User

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 17:49] by Moderator

Previous Topic:	New feature: Showing static hooks in Extdoc View
Next Topic:	Recommenders 1.0.0-rc2 ready for download

Goto Forum:

-=] Back to Top [=-

Current Time: Thu Jul 24 10:04:30 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter