Change mouse terminfo entries

[gdamore]

The mouse terminfo entries we made up (smous, rmouse) may be unnecessary. In particular, I've discovered that ncurses has created a new pair of entries called "XM" and "xm". They are somewhat different.

XM appears to be the format used for enabling & disabling mice. It uses parameterized string with the sole parameter being 0 or 1 -- 1 indicates that mouse reports should be enabled, whereas 0 indicates the reverse.

xm is the the format used for mouse reports, and is also a parameterized string. The parameters are as follows: x, y, buttons, state -- where state is either 0 for a release, or 1 for a press. The x, y coordinates are presented normally, and button codes are encoded as per x11term but without the 32 added.

The xm string is a forward processor, and doesn't really help with going in the reverse direction, which is what we need. That is, it specifies how to create a mouse event, not how to parse one. Unfortunately, this means we need to retain our custom mouse event parsing code for the time being. Its unclear how xm= could be used by any program, although it does serve as a form of documentation for developers.

Good news is that the only mouse protocols that seem to be supported are via xterm's x10mouse (9, we never use), x11mouse (1000), DEC locator mode (which appears to be nearly completely undocumented and unused anywhere), and the extended 1001 (highlight tracking, we never use), 1003, 1002, 1005 and 1006 modes. All of these strings are supplied in the latest terminfo.src exclusively for xterm.

The upshot of this is that I think we can get away doing what we have been doing -- submitting just the escape sequences for 1000, 1003, and 1006 (in that order), and then parsing mouse events as we have been, preferring the SGR form, but supporting x11 events.

In the future, maybe we can create a data driven form of xm= that goes in the reverse direction... we could also use some kind of booleans to indicate fixed protocol parsing.

That said, its probably pretty unlikely that any new mouse reporting protocols are going to be created. The SGR mode supports pretty much anything you'd want to have in a terminal, especially when combined with SGR (1003) mode.