#266 Any-event mouse tracking (1003) reports no-button motion as button 96 (SGR) / 0x80 (legacy)

[Rob Swindell]

Expected. cterm.adoc on 1003: "If no button is pressed, it acts as though button 0 is." → Pb = 32. xterm instead uses its button-3 sentinel → Pb = 35 (not in ctlseqs, but settled by button.c: FirstBitN(0) → -1 → BtnCode()'s if (button < 0) result += 3, then the SGR path subtracts the X10 bias: 32+32+3-32 = 35).

Actual. Pb = 96. In term.c:4741-4761, my_ffs(0) returns 0, so the no-button case is forced to bit = 4 → button = 3 — which is also wheel-up's pre-remap value. The if (button >= 3) button += 61 remap (there to produce xterm's 64/65) then promotes the sentinel to 64, and += 32 for motion yields 96. The sentinel is applied before the remap that reserves that range.

Two details I checked rather than assumed, and both sharpen the report:

• Mode 1002 is unaffected — the no-button case returns early at the MM_BUTTON_EVENT_TRACKING guard before reaching the sentinel. Only 1003.
• The legacy encoding is worse than the SGR one. Without 1006, Cb = ' ' + 96 = 0x80 — a non-ASCII byte, where xterm sends 'C' (67). Arguably the more serious
  symptom, since 0x80 is ambiguous in an 8-bit/UTF-8 stream.

Suggested fix, either: if (bit == 0) bit = 1; (matches cterm.adoc, gives 32), or keep the button-3 sentinel but apply it after the wheel remap (matches xterm, gives 35). I recommend flagging (2) as what xterm-targeted hosts expect, while noting (1) is what SyncTERM currently documents — and that whichever is chosen, cterm.adoc and the code should agree.

[Stephen James Hurd]

Fixed in git