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.
We have quite a fucntionality to maintain the changelof in actual state
However, since we switched to release from the latest EAP, we can't just update the changelog on master because it will contains also unreleased changes since the latest EAP.
The proper support for such change will require a lot of coding that will take a lot of time to implement and will eventually break.
So, it was decided to keep the changelog on YouTrack only and not to maintain the changes file.
This change still may be reverted, so the code around the changelog is note removed, but only commented out
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.
