Community
Participate
Working Groups
4.2 RC4. 'Line Up' and 'Line Down' no longer work in content assist pop-up. This works fine in 3.8 RC4. Steps: 1. start new workspace 2. assign a new key binding to 'Line Down' 3. paste this: "class A {}" into Package Explorer 4. invoke Content Assist (don't give focus to pop-up) 5. use the key binding from step 2. ==> in 3.8 this moves the selection in the pop-up as expected, but in 4.2 it moves down inside the editor. The code which installs the handlers can be found in: org.eclipse.jface.text.contentassist.ContentAssistant.install()
Paul, it would be great if this could be fixed for 4.2.1.
*** Bug 387650 has been marked as a duplicate of this bug. ***
*** Bug 387466 has been marked as a duplicate of this bug. ***
For me, in emacs mode, it does not work with "ctrl-p" and "ctrl-n", but it does work with the arrow keys. Workaround is to hit tab first to get focus in the autocompletion list.
ContentAssistant adds a listener so when the completion popup opens, the handlers in the various text navigation commands get replaced. This is done in org.eclipse.ui.texteditor.KeyBindingSupportForAssistant.assistSessionStarted(ContentAssistEvent) I'll have to do some more debugging to be sure, but the ReplacedCommand tries to change the handler on the command. However, in 4.2 the handler is an instance of org.eclipse.ui.internal.MakeHandlersGo which delegates to the IHandlerService. The handler replacing in KeyBindingSupportForAssistant looks like a hack that UI shouldn't support. Instead there should be a better way to switch the handler. I'm not sure if this can be done in a non-4.x exclusive way.
(In reply to comment #5) > The handler replacing in KeyBindingSupportForAssistant looks like a hack > that UI shouldn't support. That's a bold statement. Please explicitly say which APIs were not used by Platform Text as specified by their Javadoc.
(In reply to comment #6) > > That's a bold statement. Please explicitly say which APIs were not used by > Platform Text as specified by their Javadoc. The Command is API, but it's API that's used to implement the handler system in the Workbench (same way ApplicationWindow is API but it was never acceptable to extract the main MenuManager from it). Even the 3.x system can call Command.setHandler(*) at any time depending on what it's doing, and that would interfere with your code. In 4.x the framework sets, ignores, or resets the Command object handler even more aggressively. But I think I can get it working again, by examining the 4.x use of setHandler(*) and optimizing it. PW
I've done my initial work on this and pushed a work in progress up to pwebster/bug382839 Good: All the Eclipse4 command test pass. The ui execution listener tests pass. It fixes the problem described in this bug. Not so good: The ui CommandsTestSuite goes from 2e/13f to 4e/23f. Give that this is such a low-level changes to the commands infrastructure I think that it should be deferred to 4.3 PW
Created attachment 226731 [details] failure list against master Failure rate against master org.eclipse.ui.tests.commands.CommandsTestSuite 2e/12f To allow comparisons as this moves forward. PW
Created attachment 226734 [details] failure with the current patch Some stack overflow errors. PW
*** Bug 404112 has been marked as a duplicate of this bug. ***
I have actually just downloaded and tried v4.3.0, Build id: I20130204-1400 on OSX 10.8.3... still can't "line down" through Content Assist. Will a fix make it to the 4.3.0 release?
Moved the work in progress to Gerrit https://git.eclipse.org/r/#/c/11686/ PW
Getting much closer with patch set 4 https://git.eclipse.org/r/#/c/11686/4/ Down to 3e/15f in the command test suite. PW
Released into Kepler as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3e05785284f238feaf10cfc58d81efc23d9a336d PW
.
Verified in N20130418-0900.
