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
This is primarily to avoid instantiating inactive extensions when
resetting all options back to default values, which sets extensions
inactive.
It applies to global and local options, but not to global-local. The
notifications for global-local options are already complex, as they can
be reacting to changes to both the global and local value, and only
notifying editors that are affected.
Getting the effective IJ options would allow access to Vim global and IJ global, but not Vim effective. IntelliJ specific options are now a separate hierarchy, so the Vim effective and IJ effective accessors now simply access all Vim or all IJ options.
This is needed for the new way we register handlers. As we can't be sure that this commands won't be called from the `runForEachCaret` context, we have to avoid this method
Some characters that render as a single symbol can span over a sequence
of several unicode code points (e.g., flag emojis, combination of a
letter and a diacritic, Hangul syllables, etc.).
Such composites are called grapheme clusters in the unicode standard,
and this patch introduces recognition of extended grapheme cluster
boundaries, allowing to iterate over rendered characters. Without this,
user may observe the cursor being "stuck" inside a character for several
keystrokes, while it's making its way through each code point in the
grapheme cluster.
The implementation follows the boundaries search algorithm outlined in
the technical report 29 of the Unicode standard[1]. The implementation was
tested against the set of test cases provided by the unicode character
database[2].
Additionally to the grapheme cluster boundaries search itself, this
patch adds `isExtendedPictographic` function, that answers whether the
given code point has a unicode "Extended_Pictographic" property, which
is required to correctly determine grapheme cluster boundaries. This
method is implemented natively in the JDK 21 and can be removed once we
start targeting that version.
Extended_Pictographic property is stored as a bitmap. I was considering
making a similar map for the code point classification in the grapheme
cluster boundary search implementation, which could yield better
performance, but that would require adding another half a megabyte (at
least) of data into the JAR and I've settled for the bunch of `if`s way.
That is something that can be reconsidered and shouldn't be difficult to
change if the impact on performance would be noticeable (in my simple
tests it didn't show).
A few functions in the vim-engine were adjusted to handle grapheme
clusters (such as getting the horizontal offset and adjusting the cursor
to not reach over the end of the line).
[1]: https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
[2]: https://www.unicode.org/Public/UCD/latest/ucd/auxiliary/GraphemeBreakTest.txt
There was an issue that when we enter visual block, move up, then try to switch to the visual line, we get a disposed caret issue.
This was caused by the fact that we get the list of carets, then process them one by one. However, as we update the first caret, the second gets disposed.
Note that this temporarily changes the semantics of `:set` to always set the local option, instead of setting the global option (because we now eagerly initialise local values). Neither is correct, but we don't yet have a way to support the proper behaviour.
Hard wraps require figuring out the width of the panel, and all we have is the width of the associated editor, which excludes gutter, etc. Easier to let the UI toolkit handle it
