Community
Participate
Working Groups
I'm having a problem with the Java code assist inserting the wrong value into the editor. Here's an example of my problem: Let's say I have an Object o. I'll type "o." and pause for a half a second to think and the code assist comes up. If I were going to choose the notify method, I keep on typing "notify(". Once I type that "(", the code assist will insert the currently selected item in the list. Unfortunately, the editor does not seem to be able to keep up with me and the currently selected item was still "equals", so my "o.notify(" becomes "o.equals()". The same thing happens when I type in a partial method name and press "Enter". So if I were to type "noti<enter>", instead of selecting notify, Eclipse selects "equals".
Andre, can you please have a look. Please move back if there is anything JDT/UI can do.
I couldn't reproduce the problem on my 800MHz PB G4, however, I talked to Kai, and he thinks that it is possible that the opening parenthesis (or the Enter key) trigger an insertion that has not yet been completely filtered. Moving to Platform/Text
*** Bug 76444 has been marked as a duplicate of this bug. ***
Please take a look at this. It makes the code-assist almost impossible to use. I can verify that it happens to me and a friend of mine, both of us on Mac OS X.
We cannot reproduce this. To you still see this using 3.1 M4? If so, do you have additional info that could help?
I'm still seeing this in 3.1 M4. I have my code assist delay set to 0 (the only preference I changed). If I, for example, type, "System.out.", I end up with "System.class." instead. If I have a local reference of type Object named o, and I type "o.n<ctrl-space>", I end up with "o.equals()". In this second case, the ".", "n", and ctrl-space must all be typed in very rapid succession; I see the completion menu briefly, but perhaps it is never populated. If I type the ".", pause, and then type the "n" and ctrl-space in quick succession, I get the correct "o.notify". I'm using Mac OS X (10.3) on an iBook. Please reopen this bug; it makes it extremely difficult to use code assist.
Evan, did you also set auto activation delay to 0? André can you try this out on the Mac with auto activation delay set to 0?
Hmm. I see the same bug with my code-assist delay set to 1, 10, or 100, and those settings may make it easier to reproduce. I also see the same bug if I type "o.n<space>", in which case I end up with "o.equals( )".
Andre showed me the effect on the Mac. This usually happens if code assist (filtering) is slow, for example after starting up where jar loading is triggered by content assist. In order to consistenly reproduce the case, comment out the filter runnable in CompletionProposalPopup.filterProposals. After doing this, no filtering whatsoever will occur (also on other platforms). A possible solution would be to validate a proposal before inserting it.
The reason why the filtering does not occur is that the Display's async queue is flooded, so that the filtering runnables never get executed.
fixed > 20050722 CompletionProposalPopup now ensures that any pending filter runnable has executed before inserting a proposal.
possible 3.1.1 candidate?
+1
Yes. Will look at the needed changes and then decide.
Created attachment 25736 [details] CompletionProposalPopup.java.diff Patch against R3_1 of CompletionProposalPopup.java The patch moves the filtering runnable to a field and keeps track of whether a filtering operation is pending or not. This way, the filter runnable can be run directly in getSelectedProposal in the case that the posted runnable is stuck in the async exec queue.
Approving patch with a minor change: added code to prevent running the runnable a second time after returning the proposals. Committed fix to R3_1_maintenance. André please verify the fix either directly in the branch or in the next M-build.
Start verifying...
Can't verify since this is a Mac specific problem and I don't have a Mac.
I've verified that this bug no longer occurs on Mac.
