Community
Participate
Working Groups
I20151103-0800 In org.eclipse.swt.widgets.TabFolder#_getChildren(), I added this code: Control [] directChildren = super._getChildren (); int count = di Content assist at the end (after "= di") gives me an unusable proposals list. The first few entries are all constants from class Widget. Expected: Same order as when the second line is just "di".
(In reply to Markus Keller from comment #0) > I20151103-0800 I20151103-0800 contains only JDT/Core changes for substring completion. JDT/Text changes are available from N20151103-2000. There was no change done for adjusting the relevance of proposals hence this bug should be valid with N20151103-2000 also. I'll check org.eclipse.swt.widgets.TabFolder#_getChildren() for the issue.
(In reply to Markus Keller from comment #0) > The first few entries are all constants from class Widget. > Expected: Same order as when the second line is just "di". With the given example, we always get constants first in the proposal list, even without substring completion. (Can be seen by disabling "Show substring matches" in Content Assist preferences.) Now the list looks bad as we have more constants (and methods, that match the token as substring) in the list before the proposal for "directChildren". We can adjust the relevance such that all kinds of prefix matches are shown before the substring matches. Or, do we have a better solution?
How's the approach different from code recommenders subword completion? I think they did already stumble upon most of the usability issues and solved them in a decent way.
(In reply to Noopur Gupta from comment #2) I guess without substring matching, we get constants first because they actually are more relevant (their type "int" matches the type of the variable declaration). Substring matches should always be less relevant than applicable prefix matches. After "int count = di", e.g. the "dispose() : void" proposal can't produce error-free code. I think it would be OK to make substring matches more relevant if their result is assignable in the context. In cases where the result type of the proposal is not assignable to the context (e.g. "getDisplay() : Display"), substring matches should again be less relevant than prefix matches. If the relevance is computed in JDT Core, then please move this bug.
Moving to JDT/Core as the base relevance of proposals is calculated there.
New Gerrit change created: https://git.eclipse.org/r/60469
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/60469 This is only a draft and the test changes need a pass over.
Released the fix here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5e9cb8a680609e97a11e6fc9b255fcb2043219aa
In I20151201-1100 which contains the fix from comment 8 I see the following bad behavior: I completely typed all of these characters: String.valueOf(currentMethod.selector).equals("foo") but completion changed this to String.copyValueOf(currentMethod.selector).contentEquals("foo") This is worse than having no completion proposals at all. I hope this can be fixed by ensuring that a full perfect match always ranks higher than anything else, including substring matches.
(In reply to Stephan Herrmann from comment #9) > In I20151201-1100 which contains the fix from comment 8 I see the following > bad behavior: > > > I completely typed all of these characters: Stephan, I don't understand. What do you mean by completion changed it? Can you give me a complete use case for my sake? Thanks!
Sorry if it wasn't clear. Let me split into steps: (1) Type: String.valueOf (2) Type: ( -> Completion inserts to become: String.copyValueOf(|) (3) Insert argument and continue typing until you have: String.copyValueOf(currentMethod.selector).equals (4) Type: ( -> Completion inserts to become: String.copyValueOf(currentMethod.selector).contentEquals(|) In both cases it picked a proposal that is a worse match than what I had typed up-to that point. Disclaimer: I didn't even look at the list of proposals, because I was faster by just typing the 6 / 7 chars.
(In reply to Stephan Herrmann from comment #9) > In I20151201-1100 which contains the fix from comment 8 I see the following > bad behavior: According to Noopur, this is bug 483511.
Verification after jdt.ui fix
Did any change related to relevance computation make it into M4? I'm asking b/c we would need to adjust Recommenders relevance computation as well. Recommenders relevance computation is based on the JDT base relevance but has add-ons for the various subwords matchings. Thank you.
(In reply to Marcel Bruch from comment #14) > Did any change related to relevance computation make it into M4? Yes, see comment #8.
(In reply to Noopur Gupta from comment #15) > (In reply to Marcel Bruch from comment #14) > > Did any change related to relevance computation make it into M4? > > Yes, see comment #8. But it may not have any impact as the changes depend on the substringMatch option, which has been disabled for now via bug 483895.
Substring completion has been removed for M4, see bug 483895.
Verified for 4.6 M5 using I20160124-2000 build
*** Bug 538831 has been marked as a duplicate of this bug. ***
