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.
Move recording of keys to the input handler itself instead of the
Insert mode so that eventual nested modes (potentially introduced
by <a-;> will get their keys recorded as well).
Fixes#1680
When using an env var that needed the selections in the pipe command line,
say $kak_selection, the selection update code would run, modifying the
selections to adapt to eventual changes. But the rest of the pipe logic
was assuming the selections would not change, leading to bugs.
That means we can now have highlighters active at global, buffer, and
window scope. The add-highlighter and remove-highlighter syntax changed
to take the parent path (scope/group/...) as a mandatory argument,
superseeding the previous -group switch.
That way, insert mode knows when it can restore selections/avoid eol
instead of (wrongly) doing it in the destructor that ends up running
unpredictibly (as the mode is kept alive during its on_key call, even
though it can happen that it is not the active mode anymore at the end
of that call).
Fixes#1580
We were preserving the history in that case, so on fifo buffers
(that set the NoUndo flag until the fifo is closed), we still had
the history from the "previous life" of the buffer, leading crashes
when trying to apply it.
Fixes#1518
Replacing with empty strings is essentially a deletion, which means
it can end up push some selections out of the buffer (imagine 3 a
2 empty line buffer, and deleting the second one). We are fixing
the selections in SelectionList::erase, but we were not doing that
in SelectionList::insert.
Fixes#1504
Due to the way Selection::min/max worked, we were creating backward
selections, with cursor < anchor, which was triggering an assert when
trying to move cursor back one char when it was already on the first
char of the buffer.
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.
When a comment was present directly on the same line after a command,
we did not correctly see the command as terminated and would join
continue parsing the next line.
The previous implementation could yield different positions when
iterating forward and backward, leading to confusion in boost regex.
This makes an existing problem a bit more visible: iterating with
to_next and with read_codepoint wont behave the same way, as
read_codepoint will put the iterator onto the byte following the
utf8 codepoint, whereas to_next will put it on the next utf8
character start byte, which might be different if the buffer content
is not valid utf8.
Fixes#1195
That means we wont have a very nice interaction between show_whitespaces
and column highlighters, but thats the simplest fix for now, if we want
a better behaviour we need to introduce a way to know that a replaced
range is splittable (meaning it means to have the same amount of columns
as the range it replaces)
Fixes#1275
