The RegexHighlighter range cache can get pretty big in nested
regions use cases, and maintaining it can become pretty costly,
so if it hits a certain size, just drop it.
Should improve performances in #2454
This should greatly reduce memory usage by only caching matches
for ranges that needs to be highlighted, in the case where multiple
regions are nested, this means only the topmost region needs to parse
and cache the whole buffer, other regions highlighter will only ensure
the lines for the ranges they are called up are cached.
Fixes#2454
This adds a limitation that capture matching on regions only works
if the regions start/end/recurse match is less than 65635 byte long.
With this limitation we can reduce the RegexMatch struct size to 16
bytes instead of 32.
This is still not good enough,but should slightly improve high memory
usage as reported in #2454
Previously, when wrapping lines at word boundaries, we would iterate forwards
for "wrap-width" characters, then iterate backwards until we found a word-break,
which was horribly slow.
Now we record the last word-boundary we saw as we iterate forwards, getting a
result in one pass.
Fixes#2339.
Previous Implementation was constantly computing byte/column count
from the begining of the line, leading to a non-linear complexity
with respect to the length of a line.
Fixes#2146
Unfortunately Strings that start with a quoted quote (like '''str')
are still incorrectly highlighted, a deeper refactoring of the regions
highlighter will be necessary.
set-face now takes a scope argument, and faces can be overridden on
a buffer or window basis.
colorscheme apply on global scope, which should be good enough for
now.
Fixes#1411
Reference highlighters allow for potential mutual recursion between
highlighters. This is usually fine, but if the recursion happens on
the same buffer range, it means we will recurse infinitely.
Fixes#1920
To allow more general look arounds out of the actual search range,
pass a second range (the actual subject). This allows us to remove
various flags such as PrevAvailable or NotBeginOfSubject, which are
now easy to check from the subject range.
Fixes#1902
When on an end of line, certain behaviours can be surprising, for
example delete will join the following line (which makes sense, and
is consistent, but hard to predict if we do not know the cursor is
on and end of line).
As Kakoune is moving more and more towards treating end of lines
as any other character, making it clear when the cursor lies on
them seems like a good way to reduce surprise.
