When repainting the screen, we must be sure to set the cursor
to the right shape.
While the repaint is happening, hide the cursor to prevent
the cursor jumping around while the repaint happens.
When repainting a surface, we optimize for the case where lines are simple text
by combining the the `Change::Text` for the end of the previous line and the
start of the next line into a single `Change`.
The assumption about relying on automatic margins is incorrect. We can't rely
on them, as they might be disabled, and in any case they are no use if the
previous line was shorter than the full width of the screen.
This results in the lines appearing joined together on a single line. This is
evidenced in the existing tests where `"hel\nw"` becomes `"helw"` on a full
repaint.
The solution is to always inject a real CRLF by adding a `CursorPosition` change.
This replaces any CRLF that may have been swallowed by the `Surface` when it
added the original changes.
Add two new `Change` variants: `ScrollRegionUp` and `ScrollRegionDown`, which
scroll part of the screen up or down by a number of lines.
On Unix, these are implemented using the `change_scroll_region` and
`parm_index`/`parm_rindex` terminfo capabilities if available. If `parm_index`
or `parm_rindex` are not available, but `scroll_forward` or `scroll_reverse`
are, then these are used repeatedly to get the same effect.
On Windows, these are implemented using `ScrollConsoleScreenBuffer`.
The saturating_sub was going to be an attempt at the look-back alluded
to in the TODO comment, but I decided not to implement that in this
iteration.
The effect of this was that double clicking the `m` in a sequence like
` master` would only select the `m` instead of the `master` string.
previously this just used unicode word segmentation rules, but that
is insufficient for most technical users.
Change this to look for sequences that are non-whitespace and not
enclosed by bracket/quote delimiters. This allows selecting file names
with a double click, which was my main issue.
We don't yet have any code to render them, and the vte parser seems
to truncate incoming image sequences ~1kb in size, so more work is
needed to make this useful.
