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.
I came to the conclusion that the current implementation of issue 61029 (multikey binding infrastructure) is flawed. First here are the steps how to reproduce the problem - run IDE built from today's CVS - Tools -> Options -> Keymap: select Emacs - in Emacs keymap currently we have C-x C-s : Save C-x s : Save All C-x C-f: Open file C-x f: new project These are IDE shortcuts. For the editor we also have C-s: Find - have some text file open, say Hello.java, make some edits to get the file into modified state - have the welcome screen open Now: 1) switch the focus to Hello.java. C-x s (Save all) has no effect 2) switch the focus to Welcome. C-x s works 3) switch the focus to the explorer C-x s doesn't work, I get quick search popup instead 4) switch the focus to Hello.java, C-x C-s instead of Save invokes the Find dialog This is a P1 bug because it completely breaks Emacs keybindings which requires multikey shorcuts
The problem is IDE multikey shortcuts are implemented via KeyMap. The prefix keystroke switches the current IDE keymap. You should take a look at org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor first and understand how keyevents are processed there. The active TopComponent always gets the first chance at the keyevent. If it doesn't consume the event, then the IDE will try to process it as a potential shortcut. We are talking about raw keyevents, not KeyMap. Matching keyevents with shorcuts are processed in ShortcutAndMenuKeyEventProcessor itself, no Swing. The issues I see - Editor implements its own KeyMap, it doesn't know about the IDE multi-level keymaps. Thus C-s is consumed by the editor even though it's prefixed by C-x. In fact it doesn't pass C-x on at all. I see no Ctrl+X on the status line if I am in the editor, I see it if I am not in the editor - if the user presses C-x or anykey which potentially can be part of a multikey shortcut, the IDE must switch to special mode, no TopComponent should see the second keyevent). Somewhat similar to grabbing the mouse during drag gesture - even if the multikey shortcut is bound to an disabled action, the IDE should consume all the keyevents not pass it on to the TopComponent. If Save all is disabled bcs there is nothing modified to save, pressing "C-x s" in the explorer should be no-op not to invoke quick search popup with a letter 's' in it. Until 4.1 it's OK, bcs shotcuts are single-key, always hav a modifier and have no meaning in a top component. With multi-key shortcuts this is not true anymore.
I *think* we have to implement multikey shortcuts directly in ShortcutAndMenuKeyEventProcessor. Only there we can switch to the special mode when we see the prefix keyevent (like C-x). But if there are an IDE shortcut and an editor shortcut with a common prefix then we have a non-trivial problem. There such shortcuts (C-x s : save all, C-x h : select all). If I am wrong and in fact there are connections b/w editor Keymaps and IDE NbKeymap then we perhaps can solve this problem via Swing Keymap. If not then we may have to replay keyevents. Ie the editor has the first try, if it doesn't know the key sequence, then ShortcutAndMenuKeyEventProcessor gets its turn. I couldn't find such a connection in source code though :-(
Another case when it doesn't work are "C-x k" and "C-x C-k". In Emacs profile both are mapped to close current window. They work for Welcome, don't work for Hello.java. The other strange behaviour is - have both Wecome and Hello.java open, in this order (not important) [*] - select Welcome first - C-x k - Welcome is closed, focus switches to Hello.java and a letter 'k' is inserted into the document, where the carret happens to be ---- [*] it's practically impossible to use DnD to reorder the editor tabs. Perhaps we should increase the tolerance margins for drop area
> I *think* we have to implement multikey shortcuts directly in > ShortcutAndMenuKeyEventProcessor. This was the first approach I took when implementing multikey, but that didn't worked at all (the situation with propagating actions, context resets and so on were even worse). The problem with shortcuts like "C-x k" is that the action is bound to the KeyPressed event, while the "k" inserted into the editor is caused by subsequent KeyTyped. In editor keymap implementation, there is (tuned for years) code that filters such events, while the code is not in the ide keymap.
> The problem with shortcuts like "C-x k" is that the action is bound to the > KeyPressed event, while the "k" inserted into the editor is caused by subsequent > KeyTyped we could potentially eat (evt.consume()) all those subsequent KeyTyped events, the Editor cannot see them
> 4) switch the focus to Hello.java, C-x C-s instead of Save invokes the Find > dialog This case is even more funny. In fact, if you dismiss the dialog and press 's' then, it actually performs save all. That means, the editor map eats the C-s w/o notifying/reseting the IDE map.
We agreed on a small API that would allow us to keep context in both editor and core in-sync. I'll create a branch for the changes...
> explorer C-x s doesn't work Yes, because the explorer quick-search listens on, and consumes, keyPressed event from the 's' key. That's fixable in the explorer. > we could potentially eat (evt.consume()) all those subsequent KeyTyped events, > the Editor cannot see them Hardly, the editor sees them before us. Furthermore, the filtering logic is much more complicated than "all those subsequent" - you have to deal with input methods, national characters and JDK differencies. OK, it should be possible to do the filtering in ShortcutAndMenuKeyEventProcessor, as long as it will be able to interface with the rest of the system (editor, keymap).
Branched openide/awt/src/org/openide/awt/StatusDisplayer.java as context_api_64621
Branched core/src/org/netbeans/core/ShortcutsFolder.java and core/src/org/netbeans/core/NbKeymap.java as context_api_64621
*** Issue 64596 has been marked as a duplicate of this issue. ***
Not a Beta stopper.
Partial fix needed in TreeView is in trunk (harmless w/o the rest of fixes, generally positive): openide/explorer/src/org/openide/explorer/view/TreeView.java,v1.3
Branched core/windows/src/org/netbeans/core/windows/ShortcutAndMenuKeyEventProcessor.java as context_api_64621
Updated the core/src/org/netbeans/core/NbKeymap.java,v1.26.8.2 on context_api_64621 branch. so it tracks the global context instead of its private one. Should cooperate correctly with editor onse the editor starts using context API.
> We agreed on a small API that would allow us to keep context in both editor and > core in-sync. I'll create a branch for the changes... is the editor the only one which must be aware of this new API? There are other top components that handle key events on its own, for example the form designer. I haven't tried C-x <something> in the form designer, but I suspect there can be problems there If bcs of multikey shortcuts we impose new requirements on existing modules, then I wonder about backward compatibility. This may already be the case. The editor has to do something What does this mean for UML designer?
> is the editor the only one which must be aware of this new API? In theory, every component that has its own multibindings has to cooperate. For simple bindings, the situation is simpler, yet there may be problems: Global multibinding: C-X C-S Local binding: C-S Effect: the local component will eat C-S even when the global map is already in C-X context. Workaround: Selectively filter key events once the context is shifted (already implemented for KEY_TYPED events). Anyway, in my opinion, the Swing is generally far from being multikeybindings compatible and whatever we try will be an awful hack thay may just work for a while.
Created attachment 25375 [details] Current proposed patch
For fixing this issue, we need an API for components implementing any kind of multikey bindings (like NetBeans editor) as well. I'm proposing such an API. The API consists of two parts: 1. Context access methods in StatusDisplayer. A method for getting current context, resetting it and advancing the context by another KeyStroke. A context means a sequence of keystrokes that compose a prefix of some existing multi keystroke action binding. 2. A client property on components. Every component that has a private keymap implementing multikey bindings have to provide a "context-api-aware" client property and cooperate with the context api. The patch also contains fixes to the implementation of the global keymap and fixes to the editor to obey the context API.
@since tag should be used on new methods, manifest spec version shall be increased, apichange written StatusDisplayer: maybe the methods could be made final (even it is not binary compatible) and sure there should be test coverage for their mutual interaction and calls to setStatusText. You should modify arch document to mention the new property.
> @since tag should be used on new methods, manifest spec version shall be > increased, apichange written > You should modify arch document to mention the new property. Of course. I'll use superset of the info in my last comment. > StatusDisplayer: maybe the methods could be made final (even it is not binary > compatible) and sure there should be test coverage for their mutual > interaction and calls to setStatusText. Agreed.
the first fast track review failed to discover the flaw of the proposed solution. Therefore I request a formal review this time
why the new API is put in the StatusDisplayer class? This class is meant to control the text displayed in the status line. Thus the name.
Implemented a private channel between global keymap and the NB editor to allow correct implementation of multikey bindings throughout the IDE. Public API was dismissed during the review, using reflection between editor and core instead. ide/golden/deps.txt,v1.222 editor/lib/nbproject/project.xml,v1.6 editor/libsrc/org/netbeans/editor/BaseKit.java,v1.137 editor/libsrc/org/netbeans/editor/MultiKeymap.java,v1.28 core/windows/src/org/netbeans/core/windows/ShortcutAndMenuKeyEventProcessor.java,v1.15 core/src/org/netbeans/core/ShortcutsFolder.java,v1.37 core/src/org/netbeans/core/NbKeymap.java,v1.27
Where is the opinion from the review?
I've just been told by Honza that wide range of topics have been discussed which deeply analyze the problem emacs and vi support and I'd like to: 1. personally learn about it 2. keep the information in written form, so next time we do not need to reinvent a wheel Moreover I'd like to understand the motivation to create a private intercluster contract between core & editor and know what is the "get well plan". As (at least I hope) this cannot be the final solution. That is why I am searching for the opinion.
Mentioned use of reflection in the core's and editor's arch documents: Checking in core/arch/arch-core.xml; /cvs/core/arch/arch-core.xml,v <-- arch-core.xml new revision: 1.6; previous revision: 1.5 done Checking in editor/arch/arch-editor.xml; /cvs/editor/arch/arch-editor.xml,v <-- arch-editor.xml new revision: 1.29; previous revision: 1.28
The opinion document is available: Checking in opinions_64621.html; /cvs/openide/www/tutorial/reviews/opinions_64621.html,v initial revision: 1.1 Feel free to comment.
multi shortcuts are implemented in NB 5.0 - verified
This issue had *1 votes* before move to platform component