Fixed mouse movement handling when the position is greater than 127

[panicz]

There is a bug which manifests itself when one tries to use mouse pointer on the right hand side of a high-resolution terminal.
Claude Code came up with a hypothesis that I don't fully understand, and proposed a patch I don't fully understand, which seems to solve the issue.

I'm not claiming that this should be merged, but I'm sharing it for a possible future analysis.

[mabe02]

Claude Code came up with a hypothesis that I don't fully understand, and proposed a patch I don't fully understand, which seems to solve the issue.

😂

[flizaga]

Indeed that is pretty funny to use a pull request for it :D

But, I can explain what Claude Code suggested here.

So first, the changes on MouseCharacterPattern.java, are completely unrelated to the issue you are trying to fix. (The changes on this file do basically the same thing, just written in a different way)

As the X10/UTF-8(1005) mode is very messy (many softwares preferred to rely on the SGR(1006) mode), the changes will process the input at byte level instead of char level, then if it detects the X10/UTF-8(1005) mode, it will convert the mouse coordinates and button to SGR(1006) then pass the result to InputDecoder.

And for the record, Here is why it is not working as you expected in the first place :
We cannot use X10/UTF-8(1005) mode ( https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Extended-coordinates ) in the current implementation of the mouse handling in Lanterna, because we are decoding the input (InputDecoder) with Java's "InputStreamReader" who expects valid UTF-8 characters.
Because, the coordinates in this mode, are passed "encoded" as an UTF-8 char.
But some UTF-8 values (for example between 128 (0x80) and 191(0xBF)) are not valid as a first byte in the UTF-8 standard, these kind of value should be coded on 2 bytes instead of 1.
Depending on the Terminal implementation, some are doing it using two bytes for a char between 128 and 2047), some don't and are just sending a byte with the numeric value of the coordinate. For the ones who don't generate char within the valid UTF-8 ranges will generate char that the "InputStreamReader" will replace by the 'REPLACEMENT CHARACTER' (U+FFFD) as the UTF-8 standard suggest to do, which will end up in coordinates who can end up in the col or row 65533 (0xFFFD) sometimes.
The SGR(1006) mode however, does not have this issue, and add a feature for the mouse button release event, which was unclear in the 1005 mode.

That's why many softwares preferred the 1006 mode, which is easier to parse and not prone to coordinate encoding difference.

To be honest, I think it is more up to the Windows terminal (used in WSL2) to support properly the SGR mode, as it is a standard since 2012 as I explained in the pull request #631.

If I was Claude code, I would have suggested you to just use a different terminal which would be compliant. It would have saved up you some headaches and Claude code tokens ;)

[flizaga]

as a comment if someone want to implement that trick, the current PR does not do it efficiently, because it will add an overhead on each input, whether it is mouse or not, and even when it's mouse, whether it is X10 or not.
So if someone wanna do it, i think it would be clever to have a flag somewhere to apply the filter function only if we are on X10 mode and ideally only on mouse events

[mabe02]

I agree, would be good if we can apply this only when X10 mode is enabled