Mouse reporting/tracking and mouse encoding/coordinates behave incorrectly

[AutumnMeowMeow]

zellij mouse modes have the following issues. (See reference: https://www.invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-X10-compatibility-mode) (Sorry a bit scatterbrained, hopefully the gist makes it...)

• Mouse tracking and coordinate encoding are independent of each other. Selecting SGR coordinates (e.g. CSI ? 1006h) should not cause anything to be emitted unless one of the tracking modes is also enabled. For example, "CSI ? 9 ; 1006h" would cause SGR mouse button down events, but nothing else.
• "CSI ? 1002 ; 1006h" would cause SGR mouse button down, drag, and release events, which is what zellij appears to be doing with just "CSI ? 1006h".
• zellij is not recognizing DECSET with multiple parameters, e.g. "CSI ? 1002 ; 1006h" is not doing anything at all, while "CSI ? 1006h" is doing the equivalent of "CSI ? 1002 ; 1006h". I think at this spot it is reading only the first param; it needs to loop over all of the params.

grid.rs needs to add a mouse encoding (which can be just SGR (1003 h) and X10 or NONE (1003 l) in today's world) which is distinct from the mouse events to report (button down only (9), button down and up (1002), button down/up and motions (1003)).

(It would be really sweet if any-event (1003) was also supported, then a moving text mouse cursor could work happily. But that's a feature request, not a bug. :) )

[imsnif]

Thanks for the details!
While I get what you're saying about not assuming any 1006h is CSI ? 1002 ; 1006h - I think I don't fully understand the rest of your suggestions.

What other type of behaviour, aside from any-event*, should we implement? I'm just trying to avoid implementing 4-5 behaviours that no-one uses anymore :) So which ones exactly, aside from the 1002 which we're doing right now, do you suggest we implement?

*Which I think would be cool to implement for focused panes who requested it!

[AutumnMeowMeow]

(Sorry about my rambling, it was a long few weeks. :) )

Widest coverage of modern applications would be modes 1000, 1002, 1003, 1005, and 1006. BTW these can all be tested quickly in vttest under menu 11.8.5 "XTERM mouse features".

(Funny, digging though issues I see this: #1013 (comment) lol )

For the actual events being sent, just these are sufficient:

• 1000 (Normal Mouse Tracking) is just button down, and button release.
• 1002 (Button-Event Tracking) is what zellij does now: button down, move-with-button-down, and button release.
• 1003 (Any-Event Tracking) is the same as 1002, except that movements are reported whether buttons are down or not.

zellij likely already has all the information for these, it would just be minor code change to filter some events depending on mode.

For encoding, these two are good:

• 1005 is UTF-8 coordinates, and also can be the default now, i.e. if "no" encoding is specified then treat it the same as if UTF-8 encoding was set.
• 1006 is what zellij does now: SGR coordinates.

Besides the format of the string (integers as byte values vs integers printed to ASCII), the key difference between these encodings is that: UTF-8 encoding just reports a generic "release" for any combination of buttons that are released; while SGR encoding encodes the specific button that is released.

(Note that I am deliberately omitting the xterm default encoding of X10 compatibility mode (9) because it can generate invalid UTF-8 sequences. For zellij to support both UTF-8 and X10 encoding, it would have to be able to write both raw and UTF-8 bytes to the remote side at any time, which depending on architecture can be unpleasant as it breaks the nice "everything is the same encoding underneath the VT layer". I think that today's terminals should assume consistent encoding first, and then bypass that if an actual user shows up with that request.)

Here is an example on the encoding side where the events are filtered and then encoded to any of these above.

*Which I think would be cool to implement for focused panes who requested it!

It would! :)

[imsnif]

Fixed, thanks again!