Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #429262 +++ codeSelect currently doesn't find the method when the selection has length 0 and the position is before, inside, or after the "->" / "::". AFAICS, SelectionEngine lines 600-610 implement the special case for selections that span the whole "->" / "::", but if the length is 0, we end up in the if(selectionStart > selectionEnd){ branch of SelectionEngine#checkSelection(..), where this special case is missing. If there's an identifier right before or after the symbol ("C::foo", "()->doit()"), then codeSelect has two possible results at the before and after positions. The identifier should be preferred over the symbol. To reproduce, you can use the JavaElement View: Set the caret into the symbol and then click the first button in the view toolbar.
On the other hand, I would expect codeSelect to return null if just one of the symbol characters is selected. Like I get null when I just select a part of an identifier (unless that part is a full type name, but that's another story).
And on the other other hand, one could expect codeSelect to try larger and larger selections until it can return something other than null or runs out of room for further expansion :)
I suggest we get the basic hover working for GA. Which it does from JDT/Core's stand point because we return the right java element and Stephan has also verified that UI experimental patch is good for this purpose. I doubt that we will be able to address the full thing now.
There is no owner for code assist as of now.
Does that mean I could slip in some (unrelated to this bug) code assist changes I've been working on? I'm finally starting to have a pretty good feeling about these! (available already at https://github.com/Overruler/eclipse.jdt.core and https://github.com/Overruler/eclipse.jdt.ui repositories)
(In reply to Timo Kinnunen from comment #5) > Does that mean I could slip in some (unrelated to this bug) code assist > changes I've been working on? I'm finally starting to have a pretty good > feeling about these! (available already at > https://github.com/Overruler/eclipse.jdt.core and > https://github.com/Overruler/eclipse.jdt.ui repositories) Hi Timo, You are welcome to share your fixes along with regression tests. We will review the contributions and release them per project processes. We have three committers (Stephan Herrmann, Andrew Clement and Jesper Moller who made tremendous contributions to Java 8 effort starting out in this manner). Thanks!
(In reply to comment #6) > (In reply to Timo Kinnunen from comment #5) > > Does that mean I could slip in some (unrelated to this bug) code assist > > changes I've been working on? I'm finally starting to have a pretty good > > feeling about these! (available already at > > https://github.com/Overruler/eclipse.jdt.core and > > https://github.com/Overruler/eclipse.jdt.ui repositories) > > > Hi Timo, > > You are welcome to share your fixes along with regression tests. We will review > the contributions and release them per project processes. We have three > committers > (Stephan Herrmann, Andrew Clement and Jesper Moller who made tremendous > contributions to Java 8 effort starting out in this manner). Thanks! In that case, could you please /please/ review bug 431523 (it has tests! (and they pass too!))? You know I'm effectively running my own fork of JDT already with all of my fixes included in it, right? And fixing Content Assist is at the moment a three-way issue between org.eclipse.jdt.core, org.eclipse.jdt.ui and org.eclipse.jface.text, with a lot of commits that have accumulated over time. All of those plugins have different committers working at different schedules. And my Content Assist changes are good, brilliant, and they also break a lot of tests. So If I'm ever going to get those changes in I'm going to need all the help I can get. Getting in all the extra fixes that surround Content Assist will mean smaller commits when it comes to the main issue, Content Assist. Giving up on those smaller changes is unfortunately not an option, because I can only look at something that's not working right for so long before I have to fix it.
(In reply to Timo Kinnunen from comment #7) > In that case, could you please /please/ review bug 431523 (it has tests! > (and they pass too!))? Manoj is the (new) owner for formatter - he is coming up to speed on the code base. Manoj, please review the above when you have a good grasp of the formatter, TIA. Timo, I can review the code assist changes, but given vacation schedules and where Luna is (I am gone most of May), it is likely these changes will get reviewed only in early Mars.
(In reply to comment #8) > I can review the code assist changes, but given vacation schedules and > where Luna is (I am gone most of May), it is likely these changes will > get reviewed only in early Mars. Hmm, it doesn't make much sense to start preparing a patch now, then. In any case, there's still stuff about Content Assist that needs fixing, like infrequent random sub-second pauses when showing the popup. I can see from the code that if there's an autoactivation delay Content Assist wastes those milliseconds in idle waiting when it could be kicking off code completion immediately. Even if those results were immediately discarded at least it would warm up caches. That change would probably go into JFace text in platform.ui. Then after that change code completion should be easy enough to get off the UI thread completely, too...
*** This bug has been marked as a duplicate of bug 439234 ***
Verified for 4.5 M1 using I20140804-2000 build
