Community
Participate
Working Groups
Build Identifier: 20100917-0705 Eclipse completion overwrites what I type if I press Enter too fast. Reproducible: Sometimes Steps to Reproduce: * Open Java file. * import org.junit.Assert (for example) * Type "Assert.assEq" * Press Cmd-Space to get list of completion * Choose assertEquals(double, double) * Eclipse paste "Assert.assertEquals(expected, actual). "expected" word is hightlighted (selected). Eclipse also shows suggest with options "expected" and "0": http://screencast.com/t/ZmhXbUb1n * Type "1" (or any other value) AS FAST AS YOU CAN and press "Enter" to go to the next method parameter. * If you pressed "Enter" fast enough, Eclipse deletes what you just typed and paste "expected" word back. Screencast: http://screencast.com/t/TbuOxKahDwW Bug is very annoying, because it forces me too type slowly.
Markus and I could very rarely reproduce the problem. Would have to dig into the code or get more precise steps.
Steps in HEAD: - set a breakpoint in ParameterGuessingProposal#apply(..) at line 155 before "ui.enter();" with condition: Thread.sleep(5000); return false; - in the runtime workbench, have this method: void foo() { java.util.Collections.copy } - set caret after "copy" - without undue delays, press Ctrl+Space, 1, Enter => was: java.util.Collections.copy(dest, src) ... with linked field "src" selected and proposals popup visible => expected (same as when you wait until proposal is completely inserted): java.util.Collections.copy(1, src) ... with caret after ")" and linked mode terminated (In reply to comment #0) > * Type "1" (or any other value) AS FAST AS YOU CAN and press "Enter" to go to > the next method parameter. Note that Enter normally does *not* take you to the next argument position after you've typed the first argument. The Enter key only does that if the current linked position has multiple proposals and shows a proposals list. If the list is hidden, Enter takes you to the exit position. The Tab key takes you to the next linked field, and I couldn't reproduce a problem when using Tab. So, we're left with only one bug when pressing "1, Enter" very quickly: Pressing "1" doesn't immediately close the filters list (see the asyncExec(..) in CompletionProposalPopup2#filterProposals()), and if the "Enter" key is processed too quickly, the original proposals are still available and the first proposal replaces the "1" that had been typed just before. Solution: When I remove the asyncExec in filterProposals(), then I can't reproduce the problem any more. Dani, I'm not sure if we really need that asyncExec. For this scenario, it should be removed, but maybe we need to keep it for cases where the document is changed in a non-UI thread (but AFAIK, that would cause a lot of trouble in other parts of the editor).
Created attachment 188931 [details] Fix > When I remove the asyncExec in filterProposals(), then I can't reproduce the > problem any more. The asyncExec delays filtering and keeps the UI responsive for fast typers, so we should keep it. However, when the user types Enter, we need to make sure we process the outstanding filtering request and only apply proposals that fit the current document state. If no proposals are left, we should go to the exit position. I've been running with this patch in my runtime workbench for a while now, and I'm confident it's the right solution. Dani, please speak up if you don't like the fix.
Comment on attachment 188931 [details] Fix +1 for the patch.
Fixed in HEAD.
