A lot of the escape sequences on the "CSI Ps ; Ps ; Ps t" form are
expected to return a reply. Thus, not having these implemented means
we will hang if the client sends these escapes.
Not all of these escapes can be meaningfully implemented on Wayland,
and thus this implementation is best effort.
We now support the following escapes:
* 11t - report if window is iconified (always replies "no")
* 13t - report window position (always replies 0,0)
* 13;2t - report text area position (replies with margins, since we
cannot get the window's position)
* 14t - report text area size, in pixels
* 14;2t - report window size, in pixels
* 15t - report screen size, in pixels
* 16t - report cell size, in pixels
* 18t - report text area size, in cells
* 19t - report screen size, in cells
While it *looked* like the selection was working before, it really
wasn't.
When rendering, we're looking at the cells' attributes to determine
whether they have been selected or not.
When copying text however, we use the terminal's 'selection' state,
which consists of 'start' and 'end' coordinates.
These need to be translated when reflowing text.
Define a list of "tracking points" - coordinates that should be
translated while reflowing.
Add the cursor coordinates to this list.
When a coordinate have been translated, it is removed from the
list. This means we don't have to create a copy of the 'cursor'
coordinate struct.
In reset, we allocated new rows for all the currently visible
lines. We did **not** however, free the 'old' rows.
Fix by not explicitly allocating new rows, but instead allocating
uninitialized rows when needed, and then explicitly erasing the row.
If there already was a row allocated, it is simply erased. If there
wasn't, the a new line is malloc:ed, and then erased.
All are printf() formatter related. Even if a variable is e.g. a
'short', when used in an expression like '<variable> - 1' it is
promoted to an 'int'.
Closes#16
Before, we converted each axis event's scroll amount to an integer and
scrolled that many lines.
However, axis events are speed sensitive - very slow scrolling will
result in events with a scroll amount that is < 1.0.
For us, this meant we never scrolled a single line. You could slow
scroll all day if you wanted, and still we would never scroll a single
line.
Fix this by aggregating the scroll amount from axis events until the
scroll amount is > 1.0, and then scroll.
