Mouse click events can't handle > 223 rows/columns

[cookieo9]

The mouse event can only have MouseX, and MouseY values that are in the range 0 to 222 (and -33 should a coordinate be greater than 222).

This happens because the event is sent to termbox is a sequence with a single 8-bit character for each of the X and Y locations and with 33 added to them. If a click occurs outside the range, then 0 is sent as the location, so termbox reports it as -33 (due to the adjustments it makes).

Looking at http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#Mouse%20Tracking , the likely cause of this is that termbox is using X10 compatibility mode, which behaves in this manner. According to this page there are several solutions, but they might be to difficult to work with in termbox, or might drop compatability, so the simplest solution might just be to document for the user this limitation, as 222 rows/columns might be big enough for most people.

I've only tested this on OS X, using xterm, but I suspect it affects linux, and bsd systems as well. I have no idea about the situation on Windows.

[nsf]

Windows has no problems in that area for sure, there are no terminal emulators of any kind involved. I agree that the limit is probably ok, but if we can resolve that somehow propely, we will. I'm busy with other stuff, so I'm not promising anything soon (except I can add the docs about the limitation).

[cookieo9]

AFAICT, to "solve" the problem termbox would either have to do one of:

• set up the terminal to use a different mode then X10
  • (disadvantage) might drop compatibility, or require multiple chunks of code for each supported mode
  • (disadvantage) might require other parts of the event system to be re-written
  • (advantage) could allow other mouse events (mouse move, button down+up)
• set up the terminal to use utf-8 encoding
  • (disadvantage) again might affect other events
  • (disadvantage) limit is only raised to 2014(2047-33), but that is probably enough
  • (disadvantage) if the switch to utf-8 doesn't happen on the terminal side, aside from other issues, the limit is now 94 (127-33), because utf-8 only == ascii when < 128
  • (advantage) changes could be as simple as using []rune instead of []byte
• use one of the other encodings (similar [dis]advantages to utf-8)

I might explore the utf-8 option myself, since all the affected systems (where go is supported) should be recent enough to support utf-8 properly, but don't expect a pull request, as I know very little about both termbox and terminal programming to deal with non-trivial problems, and may just give up.

[nsf]

Termbox uses xterm and urxvt extended modes now if terminal can handle them. Which overcomes this limitation, but it won't work everywhere. To see how exactly your terminal reports mouse coordinates use _demos/raw_input.go. If you see something like: "\x1b[<0;76;32m", then it's the xterm extended mode. Urxvt one looks similar, it doesn't have a "<" character in the message, e.g.: "\x1b[35;76;32m". X10 mode starts with "\x1b[M".

See commit: 4aa457c414d0392fb8981c975a0b