Sometimes it's not a plugin error and may indicate that key is propagated for later handling by IDE
But what we know for sure - that for both cases we should reset command builder
Applying default values may lead to unexpected results, especially if we sometimes want to use the global state (IJ), and at other times, its clone for asynchronous processing (Fleet).
It unnecessarily binds mappingState to mode and thus to editor. And we want to simplify things and have a single MappingState instead of multiple of them
Rationale:
1. A much more experienced developer, whom I highly respect, suggested to empty VimStateMachineImpl constructor in his TODO comment.
2. I aim for VimStateMachine to be a data class rather than being a container for both data and complex logic.
3. From an architectural perspective, it is more correct. Editors do have state (or they may possess a single global state if the corresponding option is set), but a state does not own an editor.
This is done because of platform changes. Now the `lastUpdateAndCheckDumb` doesn't update an action that supposed to be updated on background.
The problem was detected with commentary tests. The test supposed to use the line comment in case the block comment is not available. However, the since the action was not updated, the presentation was not reset to false and the fallback to line action was not performed.
Because of some reason, the visual position function from the platform starts to return an incorrect column for offsets with tabs. Maybe this is a correct behaviour for the platform, but for IdeaVim it breaks the calculation of the current caret position.
The visual position for calculating the shift was used since 2003, but there is no specific reason to use it and not the buffer (logical) position. So, since it started to cause issues, it's replaced with the buffer position.
This is an old feature implemented by Rick Maddy in 2004, taken from Vim.
c294063223
If several buffers for the same file are opened, the selection is synchronized between buffers.
This doesn't happen in IJ natively and I don't see a reason to keep it like that.
This behaviour is removed because it causes issues now, but if we'll figure out the usage, we can bring it back.
In 2024.1 EAP this line causes compilation error due to platform conversion from java to kotlin
The fix is landed in the platform and it should work fine with the new EAP.
However, since our tests are fail now, I'll comment out this line and bring it back in one week.
