Bugzilla – Full Text Bug Listing
| Summary: | Child binding scheme must be reenabled on every workbench restart | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mark Feber <mcfeber> |
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | pwebster, wayne.beaton |
| Version: | 4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
Can you give an example of 2 or 3 bindings that you notice this with in your emacs+ scheme? I'll try and reproduce it in Juno. PW Here is a typical scenario: 1) un-tar a fresh juno 2) create a new workspace 3) start workbench and install my beta version of Emacs+ for juno 4) open Keys and enable Emacs+ scheme 5) edit java file - ^N conflicts, ^G and some others 6) open Keys; set to default; select Restore Defaults; exit Keys; open Keys; re-enable Emacs+ 7) overridden key bindings behave as expected 8) exit workbench 9) start workbench 10) edit java file - Now more keys conflict, ^N, ^A, etc. 11) repeat step 6 12) key bindings behave as expected 13) exit workbench 14) start workbench 15) now Emacs+ key bindings behave as expected (over additional restarts as well) On other test runs, steps 9-13 must be performed repeatedly before the keybindings "stick" and do not provoke conflicts after restart. A less severe version of this problem has plagued users of Emacs+ since Europa. Prior to Juno, asking users to perform the 'default-incantation' was marginally acceptable as it only had to be done once, and didn't appear to affect every user. In Juno, the severity of the issue may/will prevent users for being able to use Emacs+. 1) Was a bug ever filed for the pre-juno version of this behavior? (I just always assumed there was one, but never tried to ferret it out). 2) Given that this was never addressed in pre-juno versions, and despite apparent reworking of the keybinding code in juno the issue is now exacerbated, what is the chance this will be addressed in juno? There is definitely a bug where switching a scheme (especially back to Default) causes child scheme contributions to disappear for a long time. Bug 378684 I'm trying to get that fixed for 3.8.1/4.2.1 PW This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag. |
Build Identifier: Build id: 20120614-1722 I define a child scheme of org.eclipse.ui.emacsAccelatorConfiguration <scheme description="%emacsplus.scheme.description" id="com.mulgasoft.emacsplusConfiguration" name="%emacsplus.scheme.name" parentId="org.eclipse.ui.emacsAcceleratorConfiguration"/> When Emacs+ is first enabled, there are still conflicts where all key bindings that should override instead cause the Key Assist Dialog to pop up with my binding and the binding in the parent scheme on invocation. If I perform the following incantation in the Keys preference page: 1) change scheme to defaults 2) select restore defaults 3) exit Keys preference page 4) reopen Keys preference page 5) select the Emacs+ scheme again The bindings will now be enabled without conflict. If I exit and restart the workbench, I need to follow the above steps to re-enable the bindings without spurious conflicts. 1) Bug 375762 appears to be an incomplete fix 2) May be related to Bug 378684? Reproducible: Always Steps to Reproduce: 1. See above 2. 3.