Bugzilla – Full Text Bug Listing
| Summary: | [KeyBindings] Changing the keybindings to Emacs+ unstable | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Drazen Lucanin <kermit666> |
| Component: | UI | Assignee: | Paul Webster <pwebster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, mcfeber, mn, mthome, p.beauvoir, pwebster |
| Version: | 4.2 | ||
| Target Milestone: | 4.3 M6 | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 400021 | ||
|
Description
Drazen Lucanin
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 |