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.

Bug 138172 - single key binding added in StorageFilter.afterLoad doesn't replace multikeybinding
Summary: single key binding added in StorageFilter.afterLoad doesn't replace multikeyb...
Alias: None
Product: editor
Classification: Unclassified
Component: Key bindings (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: Svata Dedic
Depends on:
Blocks: 179047
  Show dependency tree
Reported: 2008-06-25 02:51 UTC by err
Modified: 2016-07-07 07:31 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description err 2008-06-25 02:51:31 UTC
Here are some email notes about the problem.
To summarize, jVi add a ^U binding but some multikey bindings starting with ^U override it.
The newly added binding never gets used.

BTW, the workaround suggested takes care of the problem. Code snippet at end.

>> >>   
>>> >>> The first problem I'm seeing has to do with 'Ctrl-U'; to jVi ^U means
>>> >>> go up half a page. It looks like this is some kind of magic to NB; the
>>> >>> ^U is not invoking the jVi action. If I enter ^U ^F, I do not get up
>>> >>> half-page, down full-page. Instead I see "Ctrl+U" in the main status
>>> >>> area, and then the ^F bring up the NB Find: dialog.
>>> >>>     
>> >> This sounds like a problem with multikey bindings. Is this working in
>> >> 6.1? 
> > Works fine in 6.1. I've never had a reported problem similar to this.
I see, I'll have to track this down. Could you please file an issue
agains editor/keybindings.

>> >> There are some actions in Nb that are bound to 'Ctrl+U U' and
>> >> 'Ctrl+U L' - they convert selected characters to upper/lower case. It
>> >> looks like these multikeybindings take precedence over your shortcuts.
>> >> Or your filter in afterLoad is not working correctly with multikeybindings.
>> >>   
> > I guess that map.put(single-key-list, binding) will leave in
> > multiple-key bindings that start with the single-key. Pre-6.5 must
> > have handled this kind of conflict? As a workaround, I could do
> >     for each jvi-binding
> >        for each nb-binding
> >           if nb-binding-key-list starts with jvi-binding-key then
> > remove/stash nb-binding
> > but order NxM algorithms are disturbing. Oh, but since jvi only binds
> > single keystrokes, I guess I can do
> >     for each nb-binding
> >        if exists jvi-binding-map[nb-binding-first-key] then
> > remove/stash nb-binding
Yes, please, that's the sort of workaround I had in my mind.

> > I'll try this as a workaround while you ponder if you want to handle
> > it in the infrastructure. I wonder if it is "random" whether or not
> > this works in 6.5?
> >

This snippet looks at every supplied NB binding. If the first key of the binding is a jVi binding then the binding is
removed from the map and saved for a later restore.

            List<KeyStroke> ksl = new ArrayList<KeyStroke>();
            Iterator<MultiKeyBinding> it = map.values().iterator();
            while(it.hasNext()) {
                MultiKeyBinding mkbOrig =;
                ksl.set(0, mkbOrig.getKeyStroke(0));
                if(mapJvi.get(ksl) != null) {
                    mapOrig.put(mkbOrig.getKeyStrokeList(), mkbOrig);
Comment 1 Vitezslav Stejskal 2008-06-25 08:20:07 UTC
Thanks for filing this Ernie.
Comment 2 err 2008-06-25 14:59:33 UTC
afterLoad is responsible for keeping track of the original bindings so that they can be restored in beforeSave. At least
for jVi. So if the infrastructure was going to automatically remove multikeybindings, it might also have to deal with
the restore issue.

From jvi's point of view, using the above code snippit that does both save and remove seems sufficient; that's just how
to do it right in the context of the new architecture. So, at least for jVi, maybe there's nothing to fix. 

A helper function like "addBindings(originalMap, newBindings)" which returned a map of bindings that are taken out of
orignalMap might be handy for situations where newBindings contained multikey bindings. In that case I guess a multikey
would could replace a singlekey. (but jvi doesn't have that case (at least not yet))

Of course, other users of the StorageFilter might have different needs.
Comment 3 Martin Balin 2016-07-07 07:31:13 UTC
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