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.
For jVi it is important to capture the proper DefaultKeyTypedAction that is associated with a given JEP. In nb6.5 the suggested strategy is to use the kit install action as the point where the editor's action can be retrieved/saved and the jVi action installed. Note that it is recommended that this action should be saved per editor, not per kit as jVi did in previous releases of NetBeans. (because the same kit may well have different DKTA) See the CODE segment below. It looks like the important DKTA is only present the first time the install action is invoked for a particular editor kit. After the first time, the jVi DKTA has already been put into the map by the infrastructure. See LOG below for a simple example. ===== LOG: 3 files open at startup: Main.java, NewClass.java, someFile.txt ~~~ KeybindingsInjector: org.netbeans.modules.jvi.Module$KeybindingsInjector@b9dc79 Module-ea85b4: kit installed: JavaKit Module-ea85b4: capture: QuietEditorPane@475614 action: JavaDefaultKeyTypedAction Module-ea85b4: capture caret Module-ea85b4: kit installed: JavaKit Module-ea85b4: MISSED CAPTURE: QuietEditorPane@10f4d89 action: EnqueCharAction Module-ea85b4: capture caret Module-ea85b4: kit installed: PlainKit Module-ea85b4: capture: QuietEditorPane@a40b6e action: ExtDefaultKeyTypedAction Module-ea85b4: capture caret >Log Session: Tuesday, July 15, 2008 3:18:58 PM PDT >System Info: Product Version = NetBeans Platform Dev (Build 200807101204) Operating System = Windows XP version 5.1 running on x86 Java; VM; Vendor = 1.5.0_12; Java HotSpot(TM) Client VM 1.5.0_12-b04; Sun Microsystems Inc. Runtime = Java(TM) 2 Runtime Environment, Standard Edition 1.5.0_12-b04 ===== CODE: invoked by jVi's registered kit install action private static void captureDefaultKeyTypedAction(JEditorPane ep) { Action a = ep.getKeymap().getDefaultAction(); if(!(a instanceof DefaultViFactory.EnqueCharAction)) { epToDefaultKeyAction.put(ep, a); // Sometimes the ep when install action has the wrong default KTA // so kleep track per kit as well EditorKit kit = ep.getEditorKit(); if(kitToDefaultKeyAction.get(kit) == null) { kitToDefaultKeyAction.put(kit, a); } ep.getKeymap().setDefaultAction( ViManager.getViFactory().createCharAction( DefaultEditorKit.defaultKeyTypedAction)); if(dbgNb.getBoolean()) { System.err.println(MOD + "capture: " + cid(ep) + " action: " + a.getClass().getSimpleName()); } } else if(dbgNb.getBoolean()) { System.err.println(MOD + "MISSED CAPTURE: " + cid(ep) + " action: " + a.getClass().getSimpleName()); } }
I'll have a look.
Is there still any problem or not?
I'm not sure what's wrong here. Closing as worksforme. Please reopen if there's still a problem to be fixed.
The behavior does still exist. (Wow, its been over a year since asked. Sorry) jVi must set up "Map<MAP_KEY, Action> toOriginalDefaultKeyAction". It was recommended that MAP_KEY be JEditorPane instead of EditorKit, because there was no guarentee that an EditorKit would always use the same DKTA. The DKTA is captured by a registered kit install action. Problem is that attempt to capture in install action (after the first time for a given ??what_key??) the JEditorPane's keymap already has jVi's DKTA. Debugging shows the reason for this is that BaseKit::getKeymap caches the keymaps (based on mimePath) so when jVi installs its DKTA it is modifying the cached keymap. Since BaseKit is caching based on mimePath (which, AFAICT, is identical to caching base on EditorKit) I can keep the current scheme where jVi maintains a layered cache, the first keyed by JEditorPane, and the second by EditorKit. You can probably just close this again. If problems show up in the future, we can look at some API support for handling the DKTA.
I am sorry but unless you provide a patch nobody will work on this. If you think this should be opened please assign to yourself and reopen.
I'll take another look. The current code is convoluted and requires jVi to make a variety of assumption that are in no way guaranteed.
I am returning this to user Err, it was migrated by change in module owner.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss