The prompt character is now implemented as a custom view, only in the UI, and not inserted directly into the text. This simplifies management of the text (and removes/fixes an exception due to manually handling prompt offset), and also allows highlighting of the prompt character.
We don't need a secondary UI element hierarchy without shortcuts because the shortcuts are no longer handled by the UI, but by the key handler. This secondary instance was used by modal input, and this is also managed by the key handler, consuming key strokes first if a modal input prompt is active
Instead of replacing the whole string, which will reset scroll position, delete or insert the required text/offsets, and let the text field manage scroll position
All key handling is done with the Vim pipeline, so make sure we don't have any Swing key bindings registered. This is quite confusing, so document what's going on
All CMD_LINE actions are registered the same as other Vim commands, which means all shortcuts are already registered with the IDE's action system. The existing VimShortcutKeyAction class will dispatch shortcuts to the key handler, where they will be handled as real CMD_LINE actions.
For visual selections spanning multiple lines, keep caret position
if it's on the first line. Otherwise move the caret to the start of
the first selected line.
Note that this implementation assumes that the 'gU' / 'gu' command in
visual mode is equivalent to 'U' / 'u'. While 'v_gU' and 'v_gu' are not
explicitly documented in Vim help, we treat these commands as identical
based on observed behavior, without examining Vim's source code.
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
