Also fixes a memory leak registering a disposable for each yank, allows config variables to be numbers rather than strings and removes highlights when IdeaVim is disabled
Fixes VIM-2236
There are a lot of incompatibilities with IdeaVim on 241 if it's built on 233
Also, this time the special branch for the IJ version won't be created. Previously on bumping the version of IJ, we've created the branch to keep the reference to the moment when it happened. However, IJ version bumps are easy to trace anyway by git.
1. Now we have two parallel commandBuilders: for the editor and for the command prompt. It's done for sequence of keys like `d/foo<C-R>"<CR>` where we have two different commands that are built at the same time.
2. We simplified the CommandConsumer and made the logic more straightforward. `/`, `?` and `:` enter the command mode, while pressing final `<CR>` fires the command execution.
Options are not reset if they've been explicitly set by the user (e.g. `:set list` or _View | Active Editor | Show Whitespaces_). They are reset if they were explicitly set in `~/.ideavimrc`.
Also bumps the IDE build number to 233.11799.241 in order to use EditorSettingsExternalizable.PropNames
It now shows visual lines relative to the caret's visual line, rather than relative to the caret's logical line. This still isn't correct, and we should be showing the relative count of Vim logical lines (buffer lines + fold lines) but this matches movement so is more helpful
While they are core Vim options, they are implemented by the host, not by the engine. If another host wants to support these options, they can add them in their implementation layer.
IntelliJ ties the hard wrap right margin guide with the other visual guides, and it's not possible to show one without the other. In Vim, you can show the hard wrap margin by adding "+0" to 'colorcolumn', so in IdeaVim, we automatically add this.
Also supports overriding local-to-buffer options with IDE values, ensuring that changes to the option/IDE value are applied to all editors for the buffer.
Fixes VIM-1310
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
Class EditorDataContext cannot be removed because it's used in github.zgqq.intellij-enhance plugin
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
This is a part of VIM-3376. This context will not be a custom EditorDataContext, but some context created by the platform.
In some places we don't have any kind of "current context", but we have to use it for the function. However, such context can be simply retrieved from the editor.
This one was added after the implementation of cmap in 5c9faba7f4
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
This context was added long ago, but I wasn't able to find specific reasons for that. Currently, such custom contexts cannot work with the intellij platform and should be refactored or removed. The issues with this context are that it cannot be converted to the async data context by the platform.
Taking the fact that the reason for this context was not found, I decided to get rid of it.
The issue from the platform looks like this
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
Here the EditorDataContext is mentioned instead of CaretAndEditorData context, however, I'll clean up both contexts during this refactoring
It was used in the action system for mapping to the `<Action>` keyword and in commit 256f5fcd0e it's mentioned that the EditorActionHandler was not working without this context. However, currently both cases work fine without addition wrapping.
Register groups for the caret do not use some fields from the base class, however the listener for these fiels is still registered. Now we don't register this listener.
Generally it looks like a bigger refactoring can be performed in order to separate the common registers logic from caret registers logic.
This change should improve the performance of the IjVimCaret initialization because now we won't register a new disposable on each instance of IjVimCaret
This is a part of VIM-3336
We want to avoid unnecessary OOP and use interfaces only for cases where we will have different implementations for different IDEs
This service will help us in our future refactorings of SearchGroup and SearchHelper
The fact that these methods only return local editors (i.e., editors for the local user while hosting a Code With Me session) is an implementation detail
This means we listen to changes in all documents, rather than just the changes in the documents for open local editors. And this means that we correctly update e.g. marks when a non-local editor changes a file that isn't open in a local editor.
Reviews all IntelliJ listeners to ensure that they only work with supported local editors. Editor creation was initialising IdeaVim for all editors, which meant that behaviour could leak into Code With Me guest editors. E.g. guest editors incorrectly drawing relative line numbers, or the host using the guest's last selected tab when switching to an alternate file.
This leads to a change in behaviour with some local editors. The editor creation listener will now check to see if the editor is local *and supported*. This means it can exclude single line editors, editors in database cells or dialogs, depending on the state of 'ideavimsupport' at creation time. The behaviour at creation time is now more correct, but if 'ideavimsupport' is modified, existing matching editors will not be initialised.
Fixes VIM-3274, fixes VIM-3275
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.
This flag is only used to modify the behaviour of visual operators, but all visual operators have the flag, which means it's unnecessary. The only behaviour for visual operators now is to exit visual mode.
Note that visual motions are implemented separately, and handle their own visual mode requirements (e.g. MotionArrowLeftAction).
However, manual removal of listeners may cause "double" remove in cause the user turns off the plugin and then closes IDE: firstly listener is removed manually, and then by dispose call
With the call that was removed, we initialized the widget too early, and the widget wasn't properly registered as disposable. This caused disposable leak.
Also, there is no understanding why this code was used to update the widget. The call for ShowCmd.update seems enough
This caused a blocker issue VIM-3124. The problem is that this ordering doesn't work well in PyCharm.
Unfortunately, this means that we have to reopen VIM-3122
Now we set the flag `executingVimscript` during execution of any vimscript and we run initialization of delayed plugins after every call for execute.
This is needed to properly initialize plugins after call for `source` command. Previously this command initialized extensions as they met in the script, what may cause incorrect behaviour. With this update, we unified an approach for executing vim script.
This includes updating the "ReloadIdeaVimRc" button and setting the correct mapping owner
Previously, the `source` command loaded ~/.ideavimrc file as a regular file, thus several features didn't work properly.
This refactoring was caused by this PR: https://github.com/JetBrains/ideavim/pull/736
In the 2023.3 EAP call to isAvailable seems to happen much earlier than it used to be.
This caused the fact that `injector` is not yet initialised at that moment and we fail with an exception. All other status bar icons are also not loaded because of this exception.
Adding `VimPlugin.getInstance()` is a quick workaround to initialize the needed injector
