Bugzilla – Full Text Bug Listing
| Summary: | child scheme keybindings that 'conflict' with parent scheme are not enabled | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mark Feber <mcfeber> |
| Component: | UI | Assignee: | Paul Webster <pwebster> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert, eclipse, jesper.eskilson, kermit666, mcooper, mn, ob1.eclipse, pwebster, steffen.pingel, wayne.beaton |
| Version: | 4.2 | ||
| Target Milestone: | 4.2 RC2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 378685, 380301, 380322 | ||
| Bug Blocks: | |||
|
Description
Mark Feber
This might be related to bug 344181 PW I started with a fresh workspace. Switched to emacs keybindings and restarted. Now hitting CTRL+L or CTRL+K in a java editor pops up the key assist dialog instead of recenter or cut to the end of line. PW Switching back to the default theme and those keybindings are inactive. Restart, and I still see the popup with both default and emacs bindings. PW See also bug 377963 PW Depends on the fixes in bug 377963 PW At the very least, org.eclipse.ui.internal.keys.BindingService.persistToModel(Scheme) looks to be wrong. It has logic to add the bindings to the runtime and handled bindings where the scheme is different but everything else is the same. It was using final Binding conflict = bindingService.getPerfectMatch(binding.getTriggerSequence()); to analyse the current active state before adding a key. But as the contexts have changed to [dialogAndWindows, dialogs] we'll never see the the CTRL+L goto line. We need to either add a method to return all current CTRL+L bindings in a given table (context) or we need to add it, and then sort out any conflicts afterwards by applying the scheme logic then. PW As per Paul's comment (bug 344181 comment 15), the fix must also fix the problem that it Edit > Find shows the wrong key binding. *** Bug 379465 has been marked as a duplicate of this bug. *** Sorry to see that this is being pushed to RC2. I can't do any testing on Juno until this gets resolved. :( (In reply to comment #9) > Sorry to see that this is being pushed to RC2. I can't do any testing on Juno > until this gets resolved. :( Most emacs keybindings work ... the problem is localized to emacs keybindings that are in parent contexts. But I believe I have a fix for that in Bug 380301. There is another problem that can occur when switching back and forth between schemes, but that's an existing 3.x problem. And comment #7 is still under investigation. PW The original problem and comment #7 have been fixed with the dependent bugs, and bug 378684 describes the other problem. PW In I20120524-2100 PW Is there a workaround for Ctrl-K not working? (In reply to comment #13) > Is there a workaround for Ctrl-K not working? Yes, see bug 378684 PW Uhm, no. Bug 378684 suggests that I "go to the keys pref page, restore defaults, and save them", but that reverts back to the default, and not Emacs, key bindings. (In reply to comment #15) > Uhm, no. Bug 378684 suggests that I "go to the keys pref page, restore > defaults, and save them", but that reverts back to the default, and not Emacs, > key bindings. yes, you have to reset the defaults. Then if you want emacs, you have to change the scheme back to emacs. PW (In reply to comment #16) > > yes, you have to reset the defaults. Then if you want emacs, you have to change > the scheme back to emacs. or not ... discussion continued on bug 378684 PW I was under the impression that the problem with Ctrl-K not working should be fixed in RC2, but I still have the same problem in RC3. To clarify: in 4.2-RC3, when using Emacs keybindings and pressing Ctrl-K, I still get a popup instead of delete-to-end-of-line. (In reply to comment #19) > To clarify: in 4.2-RC3, when using Emacs keybindings and pressing Ctrl-K, I > still get a popup instead of delete-to-end-of-line. That's related to bug 378684 PW I'm seeing this problem in 4.2 release. I've tried the workaround in 378684 with no effect. Specifically CTL-K results in the popup window with the 2 different options. Yes, still occurs on a fresh install of 4.2 with me too. Hope to see more attention to such details in the future development of Eclipse - it would add a lot to the general feeling of stability. Good quality keybinding control options are very important to programmers (see for example services such as https://www.shortcutfoo.com/ to see to what extent people go to be efficient in their IDEs). (In reply to comment #21) (In reply to comment #22) This bug here is closed. If you still see the problem using R4.2 or newer, then please file a bug with detailed steps to reproduce it. (In reply to comment #23) > (In reply to comment #21) > (In reply to comment #22) > > This bug here is closed. If you still see the problem using R4.2 or newer, > then please file a bug with detailed steps to reproduce it. OK, I filed a bug, although I couldn't find a reliable way to reproduce the pop-up appearing (it just happened on one of my installations, even though I went through the same steps): https://bugs.eclipse.org/bugs/show_bug.cgi?id=387728 |