Stop apply_diff() from creating non-monotonic changes

Commit ba41928aa (Remove spurious newline when | replaces at buffer end,
2024-11-28) also tried to fix a "DiffOp::Add" code path. Unless I'm
misremembering, I had run into a crash and extracted this unit test.

When apply_diff() decides to erase the last line, and then insert something
at the end, buffer changes might look like:

	{.type=Erase,  .begin={2, 0}, .end={3, 0}}
	{.type=Insert, .begin={1, 5}, .end={5, 0}}

The "{1, 5}" is caused by "pos = buffer.prev(pos);" added by the
aforementioned commit.  It's problematic because it breaks the caller's
"ForwardChangesTracker" invariant: the previous Erase leaves the cursor at
{2, 0}, so the insert cannot start before that.

Additionally, the inserted range returned by apply_diff() would be
"{ {2, 0}, {4, 0} }" whose end position is weirdly different from the Insert's
end position.  It questionable that we are passing on this weird state.

The "pos = buffer.prev(pos);" statement was added so we actually delete the
current final newline.  We still leave "tried_to_erase_final_newline" set,
meaning we'll also delete the the final newline after we're done.

But deleting the "current final newline" the way we do it is confusing,
because we do it at every step DiffOp::Add step.  This would blow up if
there are multiple successive contiguous DiffOp::Add events. I doubt this
ever happens but it's still confusing.

Remove this logic, and restore historical behavior in case we append at the
buffer end. This does not break the system test added by ba41928aa because
in that case, we
1. first delete the entire buffer, setting pos={0, 0}, but also restoring
   the EOL invariant, so the end position would be {0, 1}.
2. then we insert at pos={0, 0}, and since "buffer.is_end(pos)" is false we
   don't run into this bad code path.

While at it add an assertion to clarify that we already assume that the
diff algorithm never gives us empty DiffOp::Keep, and always monotonically
increasing positions, except for the very special case where we deleted
until buffer end, which should already be handled.

The unit test is not perfect because it depends on the current behavior of
the diff algorithm.

0 files changed, 0 insertions, 0 deletions