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.
Some highlighters, such as wrap or line numbers, are not intended
to be used multiple times on the same display. Add support for unique
ids that are used by highlighters to disable themselves if another
unique highlighter with the same id is supposed to override them.
The usual highlighter "precedence" takes, place, that it, that most
nested highlighter will the the one to run (window in priority to
buffer in priority to global).
Support arbitrary orders for column highlighters (it was previously
failing when column highlighters were not applied in column order).
Fix show_matching tab handling at the same time (horizontal scrolling,
tab characters and show_matching were behaving badly).
Window highlighting now runs user highlighters, then built-ins for each
phases, instead of running all phases for user highlighters, then all
phases for built-ins.
We now consider unprintable character to be 1-column width as we know
we will display them as "�".
Fixes#1615Fixes#1023
Tabs now align to tab stops instead of always spanning 8 spaces when
show_whitespaces is added as a highlighter.
This fixes issue #1453.
A regression test is also provided.
Fixes#1433 although in a slightly different way than requested:
We ensure that scrolloff *displayed* lines are visible below the
cursor, not scrolloff *buffer* lines.
Instead of highlighting full lines and then trim them to make them
fit in the window, highlight only the visible portion, and rely on
the compute_display_setup system introduced for wrapping to setup
our buffer range correctly
update-option will make the range-descs and line-descs option up to
date with the latest buffer modfications, changing the ranges/lines
to where they moved according the modifications since the timestamp
on the option.
Generalize this option type, which is a timestamped list of
<line number>|<arbitrary string>. That way this type is not strongly
coupled with the flag-lines highlighter, and can be reused for other
use cases.
range-faces are now used to replace-range highlighters, where the string
part is not interpretted as a face but as a display line, so the name was
not relevant anymore.
replace-ranges is takes a range-faces option, but treats the face
string as a display line to be parsed, and replaces the range display
with this display line.
