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.
osc.zig: undefined pointer was dereferenced when warning was issued
for handler missing
Parser.zig: too many parameters was not handled in the final case
Parser.zig: parameters being too long (>255 digits) was not handled
