Procedure to resolve keymap conflicts?

When I first wrote the Identifier Highlighter plugin for IJ6, I am pretty sure I had no keymap conflicts with the Default keymap for Shift+Alt+Left and Shift+Alt+Right.  However, I think IJ7 introduced conflicts with these shortcuts.  Therefore, anyone installing/using Identifier Highlighter on IJ7 or IJ8 get incorrect behavior as the Default keymap original actions seem to take precedence over my actions inside the plugin.

Of course, there is a fix for the user to copy the default keymap and remove the conflicting actions, but that is a lot of work required on the user's part.  I could also change my shortcuts, but my plugin has been around for a few years so I would rather not force my users to have to learn/memorize new shortcuts.

So what can I do?  Is it possible for a plugin to modify the default keymap on installation and remove the actions embedded in IntelliJ so that my plugin actions will win?  It seems unfair for me to have to always change my plugin's shortcuts everytime there is a change in IntelliJ default action shortcuts?

2 comments
Comment actions Permalink

Hello Shawn,

As for this specific issue, we've modified the actions which use these shortcuts
in Maia so that they actually take the shortcuts only when there's something
for them to do (these actions switch tabs in a multi-tab editor). So your
plugin will work correctly by default in non-multi-tab editors.

In the general case - no, there's no way for plugins to modify the default
keymap, and we don't think there should be. We want the documentation and
keymaps that we produce to be valid for all users, not only for those who
don't have a particular third-party plugin installed.

When I first wrote the Identifier Highlighter plugin for IJ6, I am
pretty sure I had no keymap conflicts with the Default keymap for
ShiftAltLeft and ShiftAltRight. However, I think IJ7 introduced
conflicts with these shortcuts. Therefore, anyone installing/using
Identifier Highlighter on IJ7 or IJ8 get incorrect behavior as the
Default keymap original actions seem to take precedence over my
actions inside the plugin.

Of course, there is a fix for the user to copy the default keymap and
remove the conflicting actions, but that is a lot of work required on
the user's part. I could also change my shortcuts, but my plugin has
been around for a few years so I would rather not force my users to
have to learn/memorize
new shortcuts.
So what can I do? Is it possible for a plugin to modify the default
keymap on installation and remove the actions embedded in IntelliJ so
that my plugin actions will win? It seems unfair for me to have to
always change my plugin's shortcuts everytime there is a change in
IntelliJ default action sh

ortcuts?

---
Original message URL:
http://www.jetbrains.net/devnet/message/5239533#5239533

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

So in the general case, what is the best solution?

1. plugin developer keeps changing shortcuts everytime IntelliJ introduces a conflict causing end user confusion?
2. IntelliJ adds a shortcut conflict resolver dialog so if a:

a. user performs a shortcut that has more than one associated action

b. IntelliJ pops up dialog stating the conflict exists

c. dialog asks user which action is preferred with "Remember" checkbox

d. if remember checkbox is NOT selected, the preferred action is used by default without popping up the conflict dialog again ONLY for this IJ session

e. if remember checkbox IS selected, then current keymap is cloned and modified to preferred behavior

f. this makes it much easier on both plugin developers AND end users since plugin developers don't have to worry as much about conflicts in the future AND end users can control this operation without having to dive into keymap editing
3. plugin clones current keymap and removes the shortcuts automatically without end user knowing?
4. something else??

0

Please sign in to leave a comment.