I am the author of the IdeaVIM plugin. Using Idea 7.0.3, Ruby plugin 1.0.14958 and IdeaVIM plugin 0.11.6-7.x there is an issue whenever editing any Ruby files. None of the VIM keybinding work while editing a Ruby file. The VIM bindings work fine for any non-Ruby file. The problem is both plugins replace the TypedAction using the EditorActionManager. Since the IdeaVIM plugin is an application level plugin and the Ruby plugin is a project level plugin, the Ruby plugin "wins".
I would have to guess that any language plugin such as the Ruby plugin would use its own TypedAction resulting in a conflict with the IdeaVIM plugin. So this bug report may not really be a bug with the Ruby plugin. It's more of a question of how is this issue best resolved?
Based on how the IdeaVIM plugin is written I believe this problem would go away if there was a way to swap the order of the TypeAction replacements. If all keystrokes went to the IdeaVIM key handler first, eventually the IdeaVIM plugin would call the "original" key handler. If IdeaVIM's "original" handler was the Ruby plugin, then all would work just fine. But since all key strokes go to the Ruby plugin first, then only to the "original" handler for non-Ruby files, then the IdeaVIM key handler is never called for Ruby files.
So how can I ensure that the application level IdeaVIM plugin is always the top level TypedAction with project level plugins being further down the chain? One kludge that would work only in this case would be for the Ruby plugin to be modified so the code that replaces the TypedAction does so in a way thee results in the correct order: IdeaVIM -> Ruby -> "original". But of course this won't help other project level plugins that also use their own TypedAction.
Does this make sense? I know it's a bit confusing to describe.
Bug
Resolved
Normal
Ruby and IdeaVIM plugins conflict with each other
But it gets even more complex. Right now the EditorActionManager is application level, not project level. What happens if I run one instance of Idea and open two projects - one using Ruby and one not using Ruby. In this case, assuming the changes have been made to ensure the app level plugin gets the key event first, the application level plugin decides to pass the key event to the original handler. The original handler would now be project specific. So there needs to be a way for the application level plugin to get the project specific handler. And this doesn't even consider module level plugins.
So the EditorActionMananger.getInstance() method probably needs to take a Project parameter or the EditorActionManager.getTypedAction needs to take a Project parameter.
To summarize, the OpenAPI and the internal framework need to be changed to support TypedAction handler chaining so a typed action can properly go from application level to project level to module level as appropriate with each level deciding how to handle the action by either consuming it or passing it on down to the next handler in the chain. Keep in mind that is should be possible for there to be multiple application and/or project level plugins in the chain at a given time. I can see another project level plugin doing what the Ruby plugin does. With these changes all should work since each language plugin would only consume the action for files specific to its language so the order of the chaining shouldn't matter at that level.
Is there any chance these changes can be made to the OpenAPI and Idea in Diana? I can't see any solution under Selena but you certainly know the internals better than me. Is there a solution for Selena?
I hope this makes sense.