This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
P1, because this makes the Emacs keymap completely broken. See also the other issue 64621 filed against IDE multikey shortcuts Steps to reproduce: - take the IDE built from today's CVS - Toos -> Options -> Keymap: Emacs - open a text file, edit it - I fould the following shortcuts don't work C-y: paste C-x u: undo ESC S-<comma> (ESC <): beginning of document ESC S-<period> (ESC >): end of document C-y and C-x u are very unpleasant bcs they are very frequent used in emacs. Inability to map them in NB makes Emacs keymap useless
Not a Beta stopper.
I have branched the particular files in the editor into context_api_64621 and continue working on a patch. Some things already work (e.g. pressing a first context key e.g. Ctrl-X outside of the editor and then finishing the shortcut inside the editor) but some others not yet.
In context_api_64621: Checking in ide/golden/deps.txt; /cvs/ide/golden/deps.txt,v <-- deps.txt new revision: 1.209.2.1; previous revision: 1.209 done Checking in editor/lib/nbproject/project.xml; /cvs/editor/lib/nbproject/project.xml,v <-- project.xml new revision: 1.5.16.1; previous revision: 1.5 done Checking in editor/libsrc/org/netbeans/editor/MultiKeymap.java; /cvs/editor/libsrc/org/netbeans/editor/MultiKeymap.java,v <-- MultiKeymap.java new revision: 1.27.76.1; previous revision: 1.27
Further fixes: Checking in libsrc/org/netbeans/editor/MultiKeymap.java; /cvs/editor/libsrc/org/netbeans/editor/MultiKeymap.java,v <-- MultiKeymap.java new revision: 1.27.76.2; previous revision: 1.27.76.1 The editor's keymap should now work properly and the initial problems from issue 64621 should now be fixed. The Ctrl+X u now works properly. The Ctrl+Y and Esc-something shortcuts do not work yet.
Ctrl+Y is still bound to Redo action in the keymap.
I do not understand why the Redo action is still bound to Ctrl+Y. I've put a debugging message that confirms that. The options dialog shows Alt+Shift+Minus or Ctrl+Shift+Z properly but the Ctrl+Y arrives as shortcut for Redo into the editor. Hanzi don't you know why this happens? I've tried to switch Emacs <-> NetBeans but it does not change anything. REDO: binding=key=ctrl pressed Y, actionName=redo java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1158) at org.netbeans.editor.MultiKeymap.load(MultiKeymap.java:146) at org.netbeans.editor.BaseKit.getKeymap(BaseKit.java:428) at org.netbeans.modules.editor.completion.CompletionImpl.findEditorKeys(CompletionImpl.java:836) at org.netbeans.modules.editor.completion.CompletionImpl.installKeybindings(CompletionImpl.java:853) at org.netbeans.modules.editor.completion.CompletionImpl.stateChanged(CompletionImpl.java:303) at org.netbeans.editor.Registry.fireChange(Registry.java:489) at org.netbeans.editor.Registry.activate(Registry.java:231) at org.netbeans.editor.BaseTextUI.installUI(BaseTextUI.java:228) at javax.swing.JComponent.setUI(JComponent.java:650) at javax.swing.text.JTextComponent.setUI(JTextComponent.java:298) at org.netbeans.editor.BaseKit.install(BaseKit.java:490) at javax.swing.JEditorPane.setEditorKit(JEditorPane.java:959) at org.openide.text.CloneableEditor.initialize(CloneableEditor.java:212) at org.openide.text.CloneableEditor.componentShowing(CloneableEditor.java:163) at org.openide.windows.WindowManager.componentShowing(WindowManager.java:307) at org.netbeans.core.windows.WindowManagerImpl.componentShowing(WindowManagerImpl.java:934) at org.netbeans.core.windows.view.DefaultView.changeGUI(DefaultView.java:144) at org.netbeans.core.windows.ViewRequestor.dispatchRequest(ViewRequestor.java:238) at org.netbeans.core.windows.ViewRequestor.processVisibilityRequest(ViewRequestor.java:227) at org.netbeans.core.windows.ViewRequestor.postVisibilityRequest(ViewRequestor.java:164) at org.netbeans.core.windows.ViewRequestor.scheduleRequest(ViewRequestor.java:85) at org.netbeans.core.windows.Central.setVisible(Central.java:74) at org.netbeans.core.windows.WindowManagerImpl.setVisible(WindowManagerImpl.java:710) at org.netbeans.core.windows.WindowSystemImpl.show(WindowSystemImpl.java:56) at org.netbeans.core.NonGui$3.run(NonGui.java:223) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Added client property filling as Petr N. requested: Checking in BaseKit.java; /cvs/editor/libsrc/org/netbeans/editor/BaseKit.java,v <-- BaseKit.java new revision: 1.135.4.1; previous revision: 1.135
Rewritten to use reflection into NbKeymap in core. In context_api_64621: Checking in libsrc/org/netbeans/editor/MultiKeymap.java; /cvs/editor/libsrc/org/netbeans/editor/MultiKeymap.java,v <-- MultiKeymap.java new revision: 1.27.76.3; previous revision: 1.27.76.2
I have removed the ExtKit.EscapeAction bound to Esc key but the Esc based shortcuts still do not work. They do not seem to be present in the keybinding settings at all. Reassigning to editor/options for evaluation. Hanzi please also see my previous comment regarding Unod/Redo bindings. Thanks. Removal of ExtKit.EscapeAction: Checking in libsrc/org/netbeans/editor/ext/ExtSettingsDefaults.java; /cvs/editor/libsrc/org/netbeans/editor/ext/ExtSettingsDefaults.java,v <-- ExtSettingsDefaults.java new revision: 1.41; previous revision: 1.40 done Checking in src/org/netbeans/modules/editor/resources/XMLs/DefaultGlobalKeyBindings.xml; /cvs/editor/src/org/netbeans/modules/editor/resources/XMLs/DefaultGlobalKeyBindings.xml,v <-- DefaultGlobalKeyBindings.xml new revision: 1.20; previous revision: 1.19 Checking in libsrc/org/netbeans/editor/ext/ExtKit.java; /cvs/editor/libsrc/org/netbeans/editor/ext/ExtKit.java,v <-- ExtKit.java new revision: 1.61; previous revision: 1.60
What is the current status of this issue? I would like to test the Emacs shortcuts, but at the moment almost none of them works. Is Escape used as the meta key? None of the shortcuts starting by Esc work for me.
We should reevaluate whats working, and whats not. Whats regular and whats random. My observation: 1) CtrlY (Paste) not working 2) CtrlX U (Undo) works for me 3) Esc Shift, (caret-begin) - does not work (seems like bug is not on my side - Mila?)
C-d used to work a week ago. It deletes the next char (like Delete). Today it seems to be bound to some other action even though in Options dialog it still maps to Delete char
Ctrl-K needs to be fixed as well.
Ctrl-D is bound now to shift line left.
Sorry for confusion, as Trung pointed out Esc-based shortcuts should not work, because the Meta key which was sometimes used as Esc is the normal Alt key on PCs.
Please note that there is issue 67187 which causes some of the multi-key shortcuts to not work (I guess only those where the prefix is only used for editor actions such as Alt-U and not for some of the system actions i.e. the Ctrl-X prefixed actions are likely unaffected). I have one suspicion regarding this issue that I'm going to check now. Hopefully we will resolve this soon.
I have been debugging the emacs shortcuts handling and I think that I know why some of the shortcuts don't work - particularly the Ctrl-Y. The whole handling is now overly complex but I'll try to explain the things. The editor's keymap loads the keybindings based on the inheritance hierarchy of the class of the editor kit for the given editor component. For example if JavaKit extends BaseKit the editor searches first for keybindings for BaseKit.class (global keybindings) and then also for JavaKit.class (java keybindings) and merges the found lists in this order (so that the JavaKit bindings can override the global keybindings). By default there are hardcoded keybindings in SettingsDefaults class (and also in ExtSettingsDefaults) that allow the editor to work from scratch even if there would not be any options that would reset the keybindings. In the old options the keybindings for BaseKit.class and JavaKit.class were loaded/set by the options as global keybindings and java keybindings. In the new options the JavaKit.class keybindings are taken from MimeLookup i.e. from the new options. The BaseKit.class keybindings however stay unaffected and so they default to the hardcoded defaults from SettingsDefaults where Ctrl-Y is bound to Redo action. Another problem is that new options map the Ctrl-Y to be a system action instead of the editor's action. Because of this the Redo action gets invoked when pressing Ctrl-Y in editor as the editor is focused component and its bound shortcuts take precedence. IMHO it would be best to disable editor's hardcoded keybindings completely and only let the new options to set the keybindings. If I do that the Ctrl-Y starts to work properly as Paste. However many regular shortcuts e.g. left/right arrow or Enter do not work in the "Emacs" profile then because they are not defined in ide/defaults/src/org/netbeans/modules/defaults/Emacs-keybindings.xml at all. The "NetBeans" profile should be OK because it uses declarative keybindings xml DefaultGlobalKeyBindings.xml from the editor module. The keybindings in that xml in fact mirror the default hardcoded keybindings so there should be no change (that xml was used for doing diffs of changes of keybindings in the old options panel against hardcoded keybindings). Anyway IMHO disabling hardcoded keybindings is the right way to go. I'm attaching the patch for disabling hardcoded keybindins. Hanzi could you please make sure that the missing keybindings will appear in the Emacs and Eclipse profile? Thanks. I still don't know though why Ctrl-D does not work at all (should be Delete in emacs). It's shown in the options properly and it's a system action as well (not editor's action) but for some reason it does not work.
Created attachment 26327 [details] Patch to disable editor's hardcoded keybindings
Hanzi, Ctrl-D in emacs does not work because it's mapped to a wrong action. The system Delete action intentionally maps to "remove-selection" (it's BaseKit.removeSelectionAction) which only removes selection if there is any. However pressing of "Del" key (or Ctrl-D) should map to "delete-next" (it's DefaultEditorKit.deleteNextCharAction) which deletes next character in the document. Reassigning back to you.
Looks like that you are not 100% correct. There are about 100 hardcoded shortcuts in editor. And at least some of them are not included in your DefaultGlobalKeyBindings.xml.
*** Issue 67739 has been marked as a duplicate of this issue. ***
According to Ctrl-D - my code does not contain any mapping between system actions <> editor actions. I thought that its implemented in editor code.
I have applied your patch + added all "hardcoded" actions to .xmls. Looks like shortcuts works, except Escape + something. Mila, can you look at it?
I've tested it and Ctrl-D works now, Ctrl-Y works now, Ctrl-K still doesn't. I've found only two Esc-shortcuts in current keymaps: Esc+Shift+Comma and Esc+Shift+Period. These keymaps have Alt-shortcuts defined as well. Do we plan some other shortcuts starting by Esc for Emacs? Note that there are side effects which appeared recently, see e.g. issue 67835. Some shortcuts also stop to work randomly, we're trying to find a reproducible scenario.
Regarding Ctrl-D: I thought it in the way that currently the Ctrl-D likely maps to (system action) org.openide.actions.DeleteAction which delegates it to "remove-selection" action in the editor. Instead we need to map to editor's "delete-next" action. Regarding Ctrl-K: we need to add mapping to "cut-to-line-end" (it's BaseKit.cutToLineEndAction) into emacs profile. I'll search for solution regarding the Esc-<key> problem.
Milo, you're right, Ctrl-D is mapped incorrectly at the moment and needs to be remapped to the correct action.
Ctrl-D: should be fixed Ctrl-K: added Alt-0 Ctrl-K:added but does not work - looks like problem in editor.
Regarding "Alt-0 Ctrl-K" I had to reopen issue 67187 - the context gets reset in NbKeymap once a modifier (Ctrl|Shift|Alt) gets pressed in a non-empty context (e.g. Alt-0).
Regarding "Esc-<key>" shortcut - I've found the culprit - the CompletionImpl consumes the "Esc" keypressed keyevent. I'm going to fix that.
*** Issue 67874 has been marked as a duplicate of this issue. ***
CompletionImpl should not consume Esc key after the following fix: Checking in completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java; /cvs/editor/completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java,v <-- CompletionImpl.java new revision: 1.22; previous revision: 1.21 done Checking in completion/src/org/netbeans/modules/editor/completion/CompletionLayout.java; /cvs/editor/completion/src/org/netbeans/modules/editor/completion/CompletionLayout.java,v <-- CompletionLayout.java new revision: 1.4; previous revision: 1.3 done Checking in completion/src/org/netbeans/modules/editor/completion/CompletionScrollPane.java; /cvs/editor/completion/src/org/netbeans/modules/editor/completion/CompletionScrollPane.java,v <-- CompletionScrollPane.java new revision: 1.4; previous revision: 1.3 done Checking in completion/src/org/netbeans/modules/editor/completion/DocumentationScrollPane.java; /cvs/editor/completion/src/org/netbeans/modules/editor/completion/DocumentationScrollPane.java,v <-- DocumentationScrollPane.java new revision: 1.7; previous revision: 1.6 Now the "Esc" followed by "<" or ">" are hitting the same problem as "Alt-0 Ctrl-K" which should be fixed in issue 67187. Now there should be no more fixes on the editor side so I'm closing this issue.