First try to break at a whitespace, if that fails (likely because
that last WORD is too long for the wrapping width), then try to
wrap at a 'word' boundary (on a non alphanumeric character).
Fixes#3048
The current implementation is wrong as it crosses basic blocks
boundaries. Doing basic block decomposition of regex is probably
a tad too complex for this single optimization.
Fixes#2711
This commit also introduces a regression in that I decided that the best way to
avoid overly long and confusing names was to rename the current shell-*
switches to script-*, and have the shell command completion be
shell-completion.
renamed script-{completion,candidates} to shell-script-*
Updated docs with new switch names
Added -shell-completion switch to x11-repl and kitty-repl
Final is more granular, it consists of FinalFg (f), FinalBg (g)
and FinalAttr (a) which control if a face's fg, bg, or attributes
fully overwrite the previous face (instead of merging) and if
following faces apply on top of this face or not.
Fixes#2388 if the Whitespace face has the FinalFg flag.
We cannot guarantee after an itersel that selections are going to
still be in ascending order, but we were calling a SelectionList
constructor that was assuming this was the case.
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
Change the logic of open line commands so that if a selection lies
on the end of line character of the line from which we open a new
line, that selection does not move.
If we have two clients, A and B, with B's cursor on the eol character
of line L, and A hits `o` while on line L, B's cursor should stay
on the same (logical) line. Previous behaviour would make B's cursor
jump on the newly inserted line.
Various places in Kakoune code used to modify selections so that
cursors would not lie on an end of line. Remove those to increase
Kakoune's consistency and simplicity.
Now that end of lines are highlighted separately, they should not
be handled specially in most commands.
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.
