This is a part of work for VIM-3935. Since we'll have to change the `CommandProcessor` execution, this may affect the "undo" command behavior. To ensure the stability, we add undo tests before making a refactoring.
This is a part of work for VIM-3935. Since we'll have to change the `CommandProcessor` execution, this may affect the "undo" command behavior. To ensure the stability, we add undo tests before making a refactoring.
This is a part of work for VIM-3935. Since we'll have to change the `CommandProcessor` execution, this may affect the "undo" command behavior. To ensure the stability, we add undo tests before making a refactoring.
This change should fix issues in Rider evaluate window and other places.
However, we may face small issues as IdeaVim will be disabled in more places than it used to be. However, this approach looks safer as before that we were disabling some random keys
If an alt+enter intention is invoked from Search Everywhere, IdeaVim's Track Action ID shows "Cannot detect action ID" instead of explaining that there is no action ID.
Relates to VIM-2541
It turned out the editor.getComponent returns not the editorComponent, but the parent of the component. This caused no problems until the AI plugin started to register enter/esc on the editor component directly. Since an editor component is more specific than the component with vim actions, the vim shortcuts were suppressed.
In this change, we start to register shortcuts on the editor component directly, allowing them to properly work on the same level as AI shortcuts. This is also the level where the shortcuts are supposed to be registered.
While it might not make sense to replay an incorrect `<Plug>` or `<Action>` mapping as characters where they are likely to cause unexpected behaviour as Normal commands, this is standard Vim behaviour (at least for `<Plug>`).
Note that `<Plug>` (and `<Action>`) is a special key code that cannot be typed. In Insert mode, Vim expands it to the text "<Plug>".
