With overlapping selections, pasting after breaks assumption of
SelectionList::for_each as our changes are no longer happening in
increasing locations.
We hence cannot rely on the ForwardChangeTracker in that case and
have to rely on the more general (and more costly) ranges update logic.
This interacts poorly with paste linewise pastes and we try to preserve
the current behaviour by tracking the last paste position.
Overall, this change really begs for overlapping selections to be
removed, but we will fix them like that for now.
Fixes#4779
They are quite different use cases, and this allow moving InsertMode
to input_handler.hh which is what uses it.
This also cleans up the code as we can get rid of get_insert_pos and
rely more on SelectionList::for_each.
Do not access Buffer::m_changes to find the inserted range, return
it directly from Buffer::insert and Buffer::replace. This fixes a
wrong behaviour where replacing at eof would lose the selected end
of line (as the implementation does not actually replace that end
of 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.
Always consider that the first selection in the list is the main
one, save selections that way.
This approach was suggested by PR #1786 but the implementation here
is different, and is used more generally whenever we save selections
to strings.
This is also the prefered way to work only on the main selection:
save selections with Z, reduce to main with <space>, restore with z.
Closes#1786Fixes#1750
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
Until now, buffer had multiple recognized end coordinates, either
{ line_count, 0 } or { line_count - 1, line[line_count - 1].length }.
Now the only correct end coord is { line_count, 0 }, removing the need
for various special cases.
Add a ColumnCount type and use it in place of CharCount whenever
more appropriate, take column size of codepoints into account for
vertical movements and docstring wrapping.
Fixes#811
