| Too many irrelevant completion proposals [message #1733337] |
Thu, 26 May 2016 14:46  |
 Alex Boyko
Messages: 9
Registered: May 2016 |
Junior Member |
|
|
List<String> l = new A<Ctrl-Space> results in many proposals that are not subclasses of java.util.List.
Is there any way to trim the proposal results down to sub-classes of the expected type?
There is a TypeCompletionSessionProcessor that creates index of subtypes. Perhaps it'd be good for this session processor to filter out irrelevant type proposals. This behaviour could be triggered with some new preference setting for instance.
I've tried to contribute my own SessionProvider to filter out irrelevant proposals not matching the expected type. However, I didn't have access to the index from TypeCompletionSessionProcessor and used IType#newTypeHierarchy(...) instead. Hence, I feel that my solution might be premature and resolving this in the core in TypeCompletionSessionProcessor is more appropriate.
Any thoughts on this? Perhaps the behaviour is already implemented and I just failed to turn it on...
[Updated on: Thu, 26 May 2016 16:07] Report message to a moderator |
|
|
| Re: Too many irrelevant completion proposals [message #1733356 is a reply to message #1733337] |
Thu, 26 May 2016 11:58  |
Andreas Sewe
Messages: 111
Registered: June 2013 |
Senior Member |
|
|
Quote:List<String> l = new A<Ctrl-Space> results in many proposals that are not subclasses of java.util.List.
Is there any way to trim the proposal results down to sub-classes of the expected type?
Just checking that I understand you correctly: Once the Subtypes-Completion Processor has computed its index and the type on the left hand side has been imported (i.e., the IDE knows that it's a java.util.List that is needed), content assist lists the subtypes of List first (marked with a star), but below you also find non-subtypes.
If so, then this is the intended behavior of the Subtypes-Completion Processor (or any other completion processor): It can reorder proposals, but won't remove them.
Or does the reordering fail to work for you? If so, please open a bug.
Quote:I've tried to contribute my own SessionProvider to filter out irrelevant proposals not matching the expected type. However, I didn't have access to the index from TypeCompletionSessionProcessor and used IType#newTypeHierarchy(...) instead. Hence, I feel that my solution might be premature and resolving this in the core in TypeCompletionSessionProcessor is more appropriate.
That being said, AFAIK it is possible with the SessionProcessor API to remove proposals, although we don't and I certainly wouldn't enable such a feature by default, as it's very easy to annoy users by this.
Hope this helps. And yes, if you are willing to contribute code for this, we should discuss this further in Bugzilla.
Best wishes.
Andreas
|
|
|
|
| Re: Too many irrelevant completion proposals [message #1733390 is a reply to message #1733374] |
Fri, 27 May 2016 07:15 |
Andreas Sewe
Messages: 111
Registered: June 2013 |
Senior Member |
|
|
Alex Boyko wrote on Thu, 26 May 2016 23:54Thanks very much for the reply, Andreas.
Yes, the non-subtypes listed below is something i don't particularly like. The order looks correct as subtypes are at the top of the list.
In other words Code Recommenders would never remove the original proposals returned by the JDT, but would rather reorder them and/or add new proposals. Is that a correct statement?
Yes, that's correct.
More precisely, we only reorder Java proposals returned by JDT, but don't add new Java proposals; we only add meta-proposals like "Code Recommenders is enabled".
Quote:What about List<String> l = new <Ctrl-Space>. This doesn't list subtype constructors. Looks like a JDT limitation to me (if I'm not mistaken), however, is that something i can request Code Recommenders to support?
Yes, this is a JDT limitation. JDT returns only type/constructor proposals when there is a non-zero prefix, so we can only reorder them in those cases.
Given the above, the feature request should go to JDT; AFAIK, they refrain from returning type/constructor proposals for performance reasons (as they don't do any subtype check, JDT would return all types/constructors on an empty prefix). Given that JDT has seen some improvements around its own indexes recently, this may be implementable efficiently now, so I suggest you ask them.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03918 seconds
] 
Search
Help
Register
Login
Home
