Previously, we would drop out of VimShortcutKeyAction when hitting Tab in Insert mode. This allowed Emmet to work because ExpandLiveTemplateByTabAction (one of the many actions registered for Tab) would have a chance to handle it.
Now we let Tab actions try to handle the key before Vim does, so we can let Vim handle Tab. In Insert mode, Vim now inserts the tab (or equivalent spaces) by invoking the "EditorTab" action, which is the same as the TabAction handler in the list of actions. Because Vim does this, we can now easily repeat inserting Tab without workarounds, remap `<Tab>` and `<S-Tab>` and Vim will update scroll locations after inserting the text.
Fixes VIM-2331. FixesJetBrains/ideavim#938. FixesJetBrains/ideavim#280
Would previously normalise against the entire buffer line length rather than just the current visual line length. For short lines, this would not include inlays, and would therefore position the caret wrong when moving up/down at end of line. For long, wrapped lines, this just plain wouldn't work.
Fixes VIM-3997
This function is not provided by vim and by using it from the plugins we may drop the digraphs created by other plugins.
It'd be better to provide a just remove function. However, let's skip it for now. Also, maybe we should use an approach with the owners
The suspending operations must not be performed under the read or write actions as this will lead to performance issues or freezes.
Also, the current implementation of launching coroutine under the write action is simply incorrect. The coroutine will escape the write action into another thread.
The current representation of Mode with `returnTo` is quite complicated and we're not even sure it'll remain like that.
At the same time, `mode()` function in Vim has quite a reach specification and there is a small chance it'll be changed. With this approach, we use values from Vim, yet in a form of enum.
`ReadImpl` didn't use anything from `VimScopeImpl`. This would make sense if `Read` inherited `VimScope`, but it doesn't.
Also, we'll always be able to bring back the dependency if we figure out it's necessary.
- We want to be able to execute functions defined on read scope under write lock as well, which means we want to have transaction extend read. However, due to conflicting names for caret scope builders (forEachCaret, withPrimaryCaret etc.) it was necessary to split it into two scopes:
1) Read - contains only functions available under read lock
2) ReadScope - contains both caret scope builders and functions defined on Read
Matt Ellis