The trailing newline was never necessary. The text field always stripped it, but the test code didn't. The previous commit pulled this behaviour out of the UI code, so the test code behaves the same as the UI.
This commit fixes all of the tests that were broken by that change. No other logic has been changed.
The ex text field and output pane will correctly resize and reposition if visible when the IDE zoom value changes. If the editor's font size is zoomed with the mouse wheel, the panels are hidden, so they do not obscure the font zoom indicator widget
Fixes VIM-3417
If IntelliJ's vertical scroll offset is set to the value of the 'scrolloff' option, IntelliJ's own implementation kicks in. This implementation includes virtual space at the bottom of the file in its calculation, scrolling to a different offset to IdeaVim's. In some circumstances, IdeaVim no longer scrolls, so the last line would no longer stick to the bottom of the screen after `G`. In other circumstances, the scroll would correctly reset, but there would be a visible flash as the editor scrolls to the wrong offset and then back, especially when using backspace at the bottom of the file.
Fixes VIM-3474
Ensures that the editor listeners are only registered once when the editor is created. IdeaVim uses two different events to track editor creation, to try to understand how the editor is being created (new window, split, preview, etc.) and this can lead to calling the `EditorListeners.add` method twice. This would create a second `Disposable` and cause handlers to leak. This is most visible when creating the first window and then disabling IdeaVim. This window would still handle drag events like IdeaVim, even changing the caret back to block after the drag finishes.
Removes a workaround that would break moving a range to the current line because it would always move the caret to the start of the range. Now positions the caret to the start of the selection if there is one. This also means we can remove the SAVE_VISUAL flag from JoinLinesCommand
Fixes VIM-2936
Handles validation of count and correctly moves caret to end of range after execution. Also fix issue where the results of :print are accumulated and not cleared.
Fixes VIM-2570
Made it explicit to get the count from argument and/or range. Default count is not passed, because it was never used. Added some tests where possible, but hard to test select file and friends
When performing a substitute command with confirmation, the height of the editor content pane should be reduced by the height of the ex entry panel. IdeaVim would do this correctly when moving a search result to the bottom of the file, but not when the result was on the last line of the file. Because the wrong height was used, IdeaVim would decide that no scrolling was necessary and the result in the last line would be obscured.
Fixes VIM-1560
This is a messy quick fix, as the search group needs a lot of tidying up right now. Perhaps a better implementation would be to move the implementation of the global command into the search group - processGlobalCommand, like we already have processSearchCommand and processSubstituteCommand
Fixes VIM-3348
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.
We should calculate the line above based on logical position rather than visual position.
This issue was detected thanks to newly introduced soft wraps and proprty tests
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
String and number/toggle options have different and opposite behaviour for `:set {option}<` and `:setlocal {option}<`. This change matches Vim's behaviour.
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.
