Xterm.js: Xterm.js's encoding of mouse coordinate

[johnpoth]

It seems there is a bit of discrepancy between Xterm.js's encoding of mouse coordinates and blessed.js's decoding when the coordinate is greater than 127. When the coordinate is greater than 127 (7bits), Xterm.js encodes it using two characters whereas blessed.js assumes just one. Furthermore, Xterm.js uses at most 11 bits for encoding. After changing the limit to 255 in Xterm.js compatibility is restored :)

After reading the spec I am not sure who is right.

I am leaving the 'Details' and 'Step to reproduce' sections blank as I don't think they are relevant here.

Let me know if you need more information,

John.

Details

• Browser and browser version:
• OS version:
• xterm.js version:

Steps to reproduce

1. 
   
   
   2.
   

[Tyriar]

In this sort of case I think it's best to see what other terminal emulators do such as iTerm2, Terminal.app, gnome-terminal, konsole, etc.

[jerch]

Btw the xterm spec notes several mouse tracking protocols, which should all be supported by xterm.js to get the best application coverage:

• X10 (old standard with limited range support, coords are limited to 256-33)
• 1005: UTF-8 encoded (basically the same as X10 but the coords are UTF-8 encoded, therefore a greater range possible)
• 1006: SGR encoded (coords as decimal SGR parameters, release vs. press is encoded by 'm' vs. 'M')
• 1015: URXVT encoded (almost the same as SGR, release is encoded by separate button definitions)

It is up to the application to choose one of those (I assume blessed uses X10 from your description).

[egmontkob]

See mc bug and first comment 2662 and bug 2956.

tl;dr: IMO implement the default (works up to coordinates 223; coordinate is always encoded as a single byte even in UTF-8, that is, the stream is not valid UTF-8) and the SGR 1006 mode, forget the other two :)