Fixes#757
The x/y is unsigned (as it should be, since top-left is 0,0). In the
case of a very small grid size and certain thickness settings, its
possible to overflow. In this scenario, the only reasonable thing to do
is just clamp to 0 because some sprites are going to look weird with
small enough grids anyways.
The XM entry enables mouse reporting events to applications. An
application that supports mouse events may not necessarily support focus
events, so these should not be bundled together.
Vim includes focus reporting mode (1004) in their example XM entry in
their docs [1], but they do not actually use it in the default value XM
value [2].
Ncurses also includes only modes 1000 and (optionally) mode 1006 in
their mouse driver [3]. The ncurses documentation for XM similarly does
not mention focus reporting (mode 1004) anywhere [4].
Including focus reporting causes bugs in some programs that want to use
mouse mode but do not handle focus events (e.g. `htop`).
[1]: https://vimhelp.org/term.txt.html#xterm-terminfo-entries
[2]: 87ca5e86fa/src/term.c (L477)
[3]: 87c2c84cbd/doc/html/man/curs_mouse.3x.html (L339)
[4]: https://www.man7.org/linux/man-pages/man5/user_caps.5.html
Fixes a crash found through fuzzing. This crash is also exhibited in
xterm (as of v384). The issue arises when you set the cursor above the top
scroll margin, then issue a large cursor left (CSI D) with extended reverse
wrap (?1045) set. Extended reverse wrap loops back until it reaches the top
scroll then wraps around. But since the cursor is before the top scroll,
xterm just arbitrarily moves back into negative row numbers, which reads into
bad memory.
We decided to fix this by clamping to (0,0) and exiting because this
will mimic the xterm behavior for valid values of cursor left count
(prior to crashing).
The resizeIncrements property is only modified when the cell size of the
focused window changes. If two splits have the same cell size then the
property is not modified when focusing between the two splits.
