Community
Participate
Working Groups
* type PlatformUI.g * content assist lists PLUGIN_ID and RETURN_EMERGENCY_CLOSE as the first matches I would expect getPreferenceStore to be the first result in this case, which it is if you actually hit ctrl+space. However when content assist is activated by typing . the matches are sorted differently than when using ctrl+space. I am finding that having substring matches enabled makes content assist much less useful, because when typing the first letters of a method name, I get a bunch of irrelevant proposals and have to either type a lot of the method name before it gets sorted to the top or use the arrow keys to select it from way down the list of proposals.
Which build? Is Code Recommenders enabled (Prefs > Java > Editor > Content Assist > Advanced)? Works fine for me in Eclipse SDK 4.7 (I20161101-0800) and 4.6.1 (M20160907-1200): getPreferenceStore() is always the first proposal after PlatformUI.g If the result of the expression is assigned to a variable, then the relevance of proposals with a matching type is increased, and PLUGIN_ID comes first here: String s = PlatformUI.g
The build is Neon.1 (4.6.1), Build id: M20160907-1200. Code Recommenders is not installed. If I uncheck "Java Proposals (Task Focused)" and check "Java Proposals" this doesn't happen. But when cycling through the proposal kinds, the Task Focused proposals also don't have this problem. So I think it has something to do with the way the "default" proposal provider is ordering things.
"Java Proposals (Task-Focused)" is provided by Mylyn and as mentioned, the problem does not happen when this is unchecked. Moving to Mylyn.
"Java Proposals (Task-Focused)" works correctly. The problem is that the default proposal computer is not sorting things correctly. I wonder if this is related to bug 461809. Moving back to JDT because I don't see how we can fix this in Mylyn. Note that "Java Proposals (Task-Focused)" is enabled by default in most distributions, so most JDT users will see this bug.
Could be related to bug 488441. The default relevance constants for JDT proposals have been changed, and that could explain problems when Mylyn and JDT proposals are to be shown in the same list.
I don't know, this happens even if the task-focused computer is the only one included in the default proposal list in preferences. Where are those relevance constants defined?
(In reply to Sam Davis from comment #6) > I don't know, this happens even if the task-focused computer is the only one > included in the default proposal list in preferences. So it's a Mylyn-only problem as Noopur said in comment 3. Standalone JDT is fine, and if you think there's a problem in a JDT API, then you have to tell us where. > Where are those > relevance constants defined? Bug 488441 comment 16 gives the commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=a9d318d978e4e9e6f3804e5aae1e81ed6e4a0136
Given that our lengthy investigation of bug 461809 did not result in a fix, I'm not optimistic the result here would be different. We will probably not have the time to dive into the JDT code base to find the bug in the default proposal computer's sorting, so I don't think this is going to be fixed any time soon.
Any progress?
*** Bug 550862 has been marked as a duplicate of this bug. ***
(In reply to Sam Davis from comment #8) > Given that our lengthy investigation of bug 461809 did not result in a fix, > I'm not optimistic the result here would be different. Are you saying this bug shares the same root cause with bug 461809? Sure, or just a guess? As it stands this group of bugs is perceived as a major regression in the content assist provided by JDT.
(In reply to Stephan Herrmann from comment #11) > (In reply to Sam Davis from comment #8) > > Given that our lengthy investigation of bug 461809 did not result in a fix, > > I'm not optimistic the result here would be different. > > Are you saying this bug shares the same root cause with bug 461809? Sure, or > just a guess? > > As it stands this group of bugs is perceived as a major regression in the > content assist provided by JDT. Indeed, I've been cursing this behavior and I assumed it to be a JDT regression. Exactly as described in 550862 I typed "map.put(" and it inserts something else that has "put" in it but not the simple obvious thing that I typed. It's seriously beyond annoying.
(In reply to comment #11) > (In reply to Sam Davis from comment #8) > > Given that our lengthy investigation of bug 461809 did not result in a fix, > > I'm not optimistic the result here would be different. > > Are you saying this bug shares the same root cause with bug 461809? Sure, or > just a guess? I do not know.
*** Bug 551814 has been marked as a duplicate of this bug. ***
*** Bug 558644 has been marked as a duplicate of this bug. ***
*** Bug 502832 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/c/mylyn/org.eclipse.mylyn.context/+/167329
*** Bug 565843 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/c/mylyn/org.eclipse.mylyn.context/+/167375
Gerrit change https://git.eclipse.org/r/c/mylyn/org.eclipse.mylyn.context/+/167329 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.context.git/commit/?id=78c4a25756ee3483de3a5750ab8039c74c2409aa
New Gerrit change created: https://git.eclipse.org/r/c/mylyn/org.eclipse.mylyn.context/+/166844
Gerrit change https://git.eclipse.org/r/c/mylyn/org.eclipse.mylyn.context/+/166844 was merged to [m_3_25_x]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.context.git/commit/?id=a5c1ddaa1e0d2a8175c3097475582fdac9afd137
*** Bug 567047 has been marked as a duplicate of this bug. ***
*** Bug 565315 has been marked as a duplicate of this bug. ***
