MotionColumnAction, MotionFirstColumnAction, MotionFirstNonSpaceAction, MotionLastColumnAction, MostionLastMatchCharAction, MotionLastMatchCharReverseAction, MotionLastNonSpaceAction, MotionLeftAction, MotionLeftMatchCharAction, MotionLeftTillMatchCharAction, MotionRightAction, MotionRightMatchCharAction, MotionRightTillMatchCharAction now have their own native multi-caret implementations.
Add basic multi-caret interfaces (i.e. deprecated and new functions to EditorActionHandlerBase) and overloaded them in MotionLeftAction and MotionRightAction.
Setting line numbers requires re-initializing the editor that means
accessing project code style settings. If the project has been disposed
then this operation is illegal.
E.g. `:action ReformatCode` is run asynchronously in another thread, so
we used to exit the visual mode (and thus dropped the selection) before
it was run.
The current version of IdeaVim is compatible with IntelliJ 2017.1+
which has switched to Java 8+, so we no longer need compatibility
layers for earlier versions.
Bear with me as this is the first thing I've ever done with
Intellij-IDEA plugin development.
I tested this and I believe I fixed the problem. The cause of the
problem was that the code was checking if the mark was in a different
file but if it was, it was using the editor of the current file to go
to the line of the mark. I changed the code so that it opens the file
of the mark first, then jumps to its line number.
I need a VirtualFile so that I can get the Editor to open. The Mark
stores the path of the file it's in, but the path is not enough
information to get a VirtualFile. I also need the "protocol" of the
file. So, I had to change the structure of the Mark and add a
"protocol" field to it.
I had to update the save/load logic to use this new field, too. This
way, when you restart Intellij-IDEA, the marks can still be used. For
old marks, I defaulted the "protocol" to the value of "file".
One thing I couldn't figure out how to do is add a test case to check
that this is working correctly. This is not due to a lack of effort.
In fact, I tried to write the test case first. But I have been unable
to find any examples anywhere of testing multiple Editors, and that's
what's involved to fix this issue. Because of this, this issue may be
best used as a reference to fix the problem instead of worthy of being
used in production. Either way, I'd love to know how to write such a
test.
On the original vim when we repeat a change with . that also contain an find movement the last find that was typed before the repeat is the one used by the motion repeat ;. Before the commit the plugin would have reset the last movement to use the movement contained in the command that was repeated.
To solve this I took a simple approach where I save the last find motion before starting the repeat and then restoring it to its original value after the repeat is over. In order to access the find motion fields from RepeatChangeAction I created getters in MotionGroup for the movement type and character.
modified: src/com/maddyhome/idea/vim/action/change/RepeatChangeAction.java
modified: src/com/maddyhome/idea/vim/group/MotionGroup.java
modified: test/org/jetbrains/plugins/ideavim/action/ChangeActionTest.java
