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.
