Community
Participate
Working Groups
200406072000 - Preferences > Workbench > Keys - choose Emacs configuration - on the Advanced tab, check "Help me with Multi-Stroke Keyboard Shortcuts" - edit a file - press Ctrl+X - wait until the popup shows up - press Ctrl+S => nothing happens (for all multi-stroke keybindings)
This is caused by a change to HandlerSubmission back in April. Handler submissions are now based on the active shell, rather than the active workbench window. This means that when the shell opens to help with the key bindings, all of the handlers that are shell-specific to the workbench window (most of them) become inactive.
Created attachment 11901 [details] Patch to "org.eclipse.ui.workbench" This patch does a few things to make this work. First of all, WorkbenchKeyboard has been changed to register the pop-up assistant shell as a window; this allows the full range of key bindings to work when it is open. Secondly, WorkbenchCommandSupport has been changed so that activeWorkbenchSite will only be null if there is no active workbench window; previously, it would be null if the active workbench window was not the active shell. The majority of the fix, however, is described a bit above. The idea is to create a middle ground where handlers can match. A handler will try to match the active shell first. If this is not possible, then it will try to match the active workbench window's shell. Priority is given to those handlers that match the active shell.
Attached patch breaks debug keybindings for Inspect and Display. Now that inspect and display are using popups, we reuse the inspect/display keybinding in the popup's shell to persist the the results. We do this by providing CommandSupport a new IHandler that reuses the command ID that opened the popup Bug 65504 and we register our shell with ContextSupport. With the patch applied, the Inspect/Display keysequences alway trigger the PopupInspectAction or PopupDisplayAction and never trigger the new handler (ie persisting the inspect/display results are impossible). If you want to see the code you can look at PopupInformationControl in the org.eclipse.debug.ui plugin.
*** Bug 66674 has been marked as a duplicate of this bug. ***
Created attachment 12033 [details] Patch to "org.eclipse.ui.test" Creates some test cases for this particular situation. The problem with PopupInformationControl is that it is relying on undocumented behaviour of handlers, which this patch is trying to change. For this patch to work, PopupInformationControl will need to specify the shell in which its handler is intended to function. In other words line 227 should be changed from: submissions = Collections.singletonList(new HandlerSubmission(null, null, null, commandId, closeHandler, Priority.MEDIUM)); ... to ... submissions = Collections.singletonList(new HandlerSubmission(null, shell, null, commandId, closeHandler, Priority.MEDIUM)); I'll open a separate bug for this, and file it against Debug. I will also check to see if anyone else might be affected by a similar situation. As it is right now, I don't believe there is a way (short of an API change) to fix this bug outside of using this patch.
I've added 3 more places where things might go wrong in debug code -- as the shell is left unspecified.
There are two other places in the Eclipse SDK where a null shell is used. Both of these are in Platform UI code. However, I don't believe either will be affected. In the first case, KeyBindingService uses a null shell, but a non-null workbench part site; the non-null site will keep it from matching when it shouldn't. The second case is the open view commands; in this case, only one such command is ever registered for each command identifier, so this also shouldn't be a problem.
Is removing the support for multi-stroke help an option?
It is, but I've heard positive feedback. And, as we are now apparently jumping on the multi-stroke key binding bandwagon (e.g., opening views), it could be even more helpful in the long. Plus, this bug does block Bug 63362, which prevents key bindings from working in detached views.
working on 66990 (with this workbench patch applied) I noticed some unexpected behavior. If you have the breakpoint properties dialog open, and the Enable Condition checkbox selected, then do a Ctrl-A inside the Text area, the code in the open source file (ie underneath the dialog) gets selected.
Created attachment 12304 [details] Patch to "org.eclipse.ui.workbench" This patch did not consider the case where the workbench window submission included a site. Both the exact match and the partial match would be considered, and the partial match would win because it specified a non-null site. The patch now only allows the site to win if it is a better shell match. (That sentence probably makes little sense, but just go with it.)
Patch has been reviewed by both Kevin Barnes and Tod Creasey. It has been committed to CVS, and should appear in I200406161600.
This causes a regression in the dialog handling code. The current cut/copy/paste/selectAll handlers are submitted as null/null/null submissions, which means that they can never beat the text editor submissions.
Handlers submitted through XML are given priority iff a dialog is currently open. The patch has been reviewed by Tod Creasey, and submitted to CVS. It is expected to appear in I200406170800.
*** Bug 67611 has been marked as a duplicate of this bug. ***
Verified to be fixed in I200406170800, GTK+ 2.4.1, KDE 3.2.2, Linux 2.6.4. This has been tested by using the "show view" commands. There is one limitation to this fix -- specifically its interaction with Bug 63362. If a detached window has focus and then the multi-stroke pop-up appears, the keys won't be dispatched properly. For example, using the "show view" commands from a detached view with the multi-stroke pop-up is active will not work. Note, in this case, you can still use arrow keys in the pop-up to select an item and then press enter to activate it.
I can confirm that this work like a charm with I200406170800 on WinXP, too.
