Since classloading of the IntelliJ platform takes a lot of time,
using forkmode=once in the Ant file makes running the unit tests from
Ant much faster (down to 16 seconds from 93 seconds) and is also more
closer to how the tests are run in the IDE.
The current visual block mode implementation has several bugs:
- The GUI never displays the rightmost characters as selected (blue)
- Due to some off-by-one, commands can't act on each line's last character
- It's possible for newlines to get deleted/changed into something else
- If the '$' mode is entered, the GUI doesn't always indicate this
- It's impossible to move to an empty line (VIM-781)
This commit fixes all of those problems. The only remaining problem are
the visible secondary carets, which makes seeing the real cursor a bit
difficult. This could be fixed later if support for per-caret visibility
would be added to IntelliJ core.
The regex code has the following bugs, mostly related to lookbehind:
- Comparison of CharPointers with == is wrong, .equals should be
used instead.
- In the original C code, the behind_pos variable is declared as
'static regsave_T behind_pos;', i.e. not a pointer, and the same
for other variables of type regsave_T. So assignments to these
types of variables need to make deep copies.
Adds tests for ranges in Ex commands. Almost every kind of range has
basic tests, except the following are still totally untested:
- \/, \?, \&
- register ranges
- syntax errors in ranges
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.
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.
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.
This commit allows the Ex command '!' to be ran without a range, with
the results displayed in a window.
For example, run ':! ls' in normal mode for a quick directory listing.
When a visual mode command is repeated, code calls into
MotionGroup#toggleVisual() to setup a 'fake' visual mode selection. But
when MotionGroup.moveCaret() is called, it notices that the indent
command has the FLAG_EXIT_VISUAL flag, and leaves visual mode right
away.
Tuomas Tynkkynen