Community
Participate
Working Groups
Using the emacs key settings for editing. The standard settings has CTRL+E set to "Window/Open Editor Drop Down" which Emacs uses for "End of Line" when editting text. The default when editing text is the editor drop down action. I go to Preferences/General/Keys and edit the "Window/Open Editor Drop Down" entry and Remove the editor drop down entry for CTRL+E (leaving the alternate entry of "CTRL+X B" for this action) and hit Apply and OK and everything works as expected. However, on quiting and restarting, the "Window/Open Editor Drop Down" binding is back. I thought that this might be related to bug 86750, but using the -data option gave the same results; so, I'm not sure if it's the case that it's not being saved or it's not being restored.
Okay, I'm not entirely clear as to your set-up. You are using the "Emacs" scheme rather than the "Default" scheme? In this case, there is no "Ctrl+E" binding for "Open Editor Drop Down" ... there is only "Ctrl+X B". Could you perhaps attach your "<workspace>/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.workbench.prefs" file?
Created attachment 25982 [details] org.eclipse.ui.workbench.prefs file I note that there are two entries for CTRL+E: one for contextId\="org.eclipse.ui.textEditorScope" and one for contextId\="org.eclipse.ui.contexts.window".
You're right. <keyBinding contextId="org.eclipse.ui.textEditorScope" keyConfigurationId="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence="CTRL+E"/> <keyBinding contextId="org.eclipse.ui.contexts.window" keyConfigurationId="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence="CTRL+E"/> Which means that "Ctrl+E" is being unbound in both the global and text editor scope. So, what does the preferences file look like after you hit "OK" and everything works?
(In reply to comment #3) > You're right. > Which means that "Ctrl+E" is being unbound in both the global and text editor > scope. So, what does the preferences file look like after you hit "OK" and > everything works? That was it. The time stamp changed; so, the file was written out, but it never deletes the window setting.
Okay, I'm not sure how you got your preferences file into this state. I can't seem to get my preference file to look like yours. But, if I just copy your preference file, then I end up in the bad state you describe.
Okay, I think I understand what is going on. The problem is that there are two unbindings. In BindingManager.removeDeletions(), it doesn't defend against the duplicate case. It just clobbers a value in a map: deletions.put(binding.getTriggerSequence(), binding); So this means that if the second deletion read doesn't match the context, then no real deletion happens. This is bad. In more complex context hierarchies, there could even be legitimate uses of multiple deletion markers for the same binding. I think probably what happened here is that the CTRL+E was removed from the "Go to End of Line" command, and also from the "Open Editor Drop-Down". This ended up with two deletion markers, which then just confused BindingManager.
Created attachment 26062 [details] Patch to "org.eclipse.jface" Okay, I believe this patch fixes this problem. I'm going to commit it to CVS, and it should start appearing in nightly builds -- starting tonight. Could you either try the patch or try N20050813-0010 or I20050816-0800?
Marking as FIXED. Please re-open if this doesn't work for you....
I've fixed this on the R3_1_maintenance stream as well, so it will appear in 3.1.1.
The fix for this bug contained a bug itself. See Bug 109011.
Verified that "Ctrl+E" does nothing with the provided prefs file in both 3.1.1 RC2 and 3.2 M2. GTK+ 2.6.8.
