Substitution commands with offset ranges like .,+2s/a/b/g previously
did not work the way they do in Vim (replace a with b on the current
line and the next two lines). This change fixes that bug.
Previously, if the editor window had been splitted, under certain
conditions some actions related to the Ex panel would cause the editor
focus to change to a different split.
The required conditions for this bug to occur:
- no docked windows (like the Project sidebar) are open
- 'View -> Navigation bar' is disabled
At least these actions triggered the bug:
- search with /
- successfully executing an Ex command
- dismissing the Ex window with Esc
- Ex commands that opened the output panel (e.g. :!)
All the deleted lines of the form
FileEditorManager.getInstance(project).openFile(vf, true);
seem to be very old, non-functional workarounds for the focus issue.
Previously strchr and istrchr didn't consider NUL chars as end-of-string
terminators. This caused problems in regexps using character classes:
a regexp like "[^a]bc" would be effectively treated as "[^abc]bc" - i.e.
some literal characters from the rest of the pattern would accidentally be
included in the character class.
The previous code threw "cannot share data context between Swing events"
throwables from DataManagerImpl$MyDataContext.getData since we used to
share DataContext objects passed to
VimShortcutKeyAction.actionPerformed() and
VimTypedActionHandler.execute() inside AnActionEvent objects with
runnables we invoked via SwingUtilities.invokeLater().
If the replacement contains newlines, the line number of the current
search position needs to be adjusted. Without this, e.g. s/$/\r/g would
get into an infinite loop.
Annotations-based line numbers reset all other annotations on caret
move, so the results of VCS annotate are reset all the time. It is
necessary for 'rnu', but for 'nu' we can use standard editor line
numbers and preserve the ability to show VCS annotations during caret
movement operations.
Previously, performing e.g. visual '~' on a large file would completely
lock up the IDE. The culprit seemed to be the calls to replaceText() one
character at a time, which is not a cheap operation since each
replaceText() will for example trigger a DocumentChanged event.
Based on empirical testing with Vim, ';' should work like this:
assuming "<caret>1:a 2:b 3:c" with ':' as the last f/t character:
- "t:" does nothing
- ";" cursor goes to '2'
- "2;" cursor goes to '2', same as the previous
- "3;" cursor goes to '3'
If first character of the file is a newline, then findSentenceEnd()
could return -2 when the 'previous sentence' motion is performed,
leading to an eventual crash. Found by fuzzing.
The '<' and '>' commands weren't marked with FLAG_OP_PEND even though
they should, which sometimes caused EmptyStackException in KeyHandler
(when typing <I<><I<> for example). Found by fuzzing.
