Community
Participate
Working Groups
Steps to reproduce: ------------------- Install Eclipse 4.2 JEE. Add the Emacs+ software update site: Emacs+ - http://www.mulgasoft.com/emacsplus/juno/update-site Install the plugins: - Emacs+ - Emacs+ options Accept to restart. Go to Window-Preferences-General-Keys and select the Emacs+ scheme. Symptoms -------- - after selecting the new scheme, it often doesn't do anything (e.g. ctrl+p and ctrl+n inside the editor don't actually move the cursor, but open a print or new.. dialog) - one has to do the following steps to get the change of bindings accepted: + Change the binding scheme to default + Select the Restore Defaults button + Exit Preferences + Re-enter Preferences -> General -> Keys + Re-enable the scheme Emacs+ Scheme - after a restart, the bindings sometimes turn back to default - sometimes (I think when connecting to an Eclipse 3.x workspace, can't reproduce it reliably) a pop-up bubble shows up when there are duplicate keybindings (e.g. "home" and "end" keys) where the user has to choose which of these he meant (and they are usually the same in practice - such as "forward word" vs "next word").
Might be related to bug 378684 (any switching of scheme could cause certain keybindings to be removed for that workspace). That'll have a fix in 4.2.1 PW
Yes, seems to be related. Although, I don't find the pop-up bubble (mentioned in that bug report as well) to be a "good and expected" solution. I would expect the most recently selected binding (in this case the one defined in the emacs scheme, which was selected by the user *after* installing Eclipse) to be applied. Will wait for the 4.2.1 update to see how it affects my installations. Regards, Dražen (In reply to comment #1) > Might be related to bug 378684 (any switching of scheme could cause certain > keybindings to be removed for that workspace). > > That'll have a fix in 4.2.1 > > PW
Despite marking https://bugs.eclipse.org/bugs/show_bug.cgi?id=375762 fixed, it is not. Just found the time to test it using: Eclipse SDK Version: 4.2.1 Build id: M20120912-1200 Enabling the Emacs+ bindings results in the key conflicts pop-up (as it has since the first Juno). change/restore/change incantation is still required.
(In reply to comment #3) > Version: 4.2.1 > Build id: M20120912-1200 > > Enabling the Emacs+ bindings results in the key conflicts pop-up (as it has > since the first Juno). change/restore/change incantation is still required. What's the general pattern of an emacs+ keybinding that's not working? What's the XML? Is it defined off of the emacs scheme that ships with eclipse? PW
(In reply to comment #4) > (In reply to comment #3) > > Version: 4.2.1 > > Build id: M20120912-1200 > > > > Enabling the Emacs+ bindings results in the key conflicts pop-up (as it has > > since the first Juno). change/restore/change incantation is still required. > > What's the general pattern of an emacs+ keybinding that's not working? > What's the XML? > > Is it defined off of the emacs scheme that ships with eclipse? > > PW As described in Bug 375762: <scheme description="%emacsplus.scheme.description" id="com.mulgasoft.emacsplusConfiguration" name="%emacsplus.scheme.name" parentId="org.eclipse.ui.emacsAcceleratorConfiguration"/> A typical binding looks like: <key commandId="com.mulgasoft.emacsplus.nextLine" contextId="org.eclipse.ui.textEditorScope" schemeId="com.mulgasoft.emacsplusConfiguration" sequence="CTRL+N"/>
(In reply to comment #3) > Eclipse SDK > > Version: 4.2.1 > Build id: M20120912-1200 > > Enabling the Emacs+ bindings results in the key conflicts pop-up (as it has > since the first Juno). change/restore/change incantation is still required. If your workspace is in the state pop, then the change/restore/change incantation would be required, even in 4.2.1. But switching to Emacs+ in a new workspace (I'll test some stuff out today) should not put you in the bad-popup/not-working state. PW
(In reply to comment #6) > (In reply to comment #3) > > Eclipse SDK > > > > Version: 4.2.1 > > Build id: M20120912-1200 > > > > Enabling the Emacs+ bindings results in the key conflicts pop-up (as it has > > since the first Juno). change/restore/change incantation is still required. > > If your workspace is in the state pop, then the change/restore/change > incantation would be required, even in 4.2.1. > > But switching to Emacs+ in a new workspace (I'll test some stuff out today) > should not put you in the bad-popup/not-working state. > > PW Tried 3 different scenarios; all failed... 1) - create empty directory foo-workspace - untar and launch fresh juno build - use foo-workspace - load emacs+ - enable emacs+ scheme - create java project/class - ^F ^B and others cause spurious popup 2) - remove .metadata from foo-workspace - untar and launch fresh juno build - use foo-workspace - load emacs+ - enable emacs+ scheme - import existing project - ^F ^B and others cause spurious popup 3) - untar and launch fresh juno build - use foo-workspace - load emacs+ - enable emacs+ scheme - edit in existing project - ^F ^B and (many many) others cause spurious popup
OK, the problem is that although the runtime can look up different commands based on scheme the definition in org.eclipse.e4.ui.bindings.internal.BindingTable.addBinding(Binding) doesn't take the different schemes into account and marks them as in conflict. I'll concentrate on addBinding/removeBinding. PW
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b072a39d8e72b21a894353793cf7a1ea04b932a4 is a preliminary patch that tries to keep one binding as active and stack the other bindings in a superceded list. While this solves the use case in this bug, I think this idea needs more work, especially around transferring bindings between active, superceded, and conflicts. PW
*** Bug 385126 has been marked as a duplicate of this bug. ***
Here's a better take on the situation http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=893b556ec54f42fa7bf101ec16b65613e4b81b1c With only one binding in a context, we only store that one binding. With 2 or more contexts in a binding, we store them in an ordered list by trigger sequence. Then the first 2 bindings are compared, and either they conflict or one is the winner and is promoted (no conflict) PW
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0fbbfb1bd4d8f09828bc358be83af63c78b2c1cc PW
