bug#17378: 24.3.1: xterm-mouse-event: Wrong type argument: wholenump, -6

[Stefan Monnier]

> ESC [ M SPC \263 A

That's down-mouse-1 (at position 147,33)

> ESC [ M # \263 A

That's the matching up-mouse, mapped (via xterm-mouse-last) to mouse-1.

> ESC [ M ` \260 ?

That's (up-)mouse-4.  There's no matching down-mouse-4 and that's normal.

> ESC [ M a \260 ?

That's (up-)mouse-5.  There's no matching down-mouse-5 and that's normal.

> ESC [ M # \260 ?

Hmm... that's an "up-mouse" but there was preceding down-mouse, so we
don't know the button number to use.  The code defaults to map it to `mouse-1'
but we really have no idea.

> ESC [ M a \260 ?
> ESC [ M # \260 ?

Same pair seen a few times.

> ESC [ M a \260 ?
> ESC [ M a \260 ?

And here we see (up-)mouse-5 events not followed by the odd "up-mouse",
so that makes those "up-mouse" even more strange: sometimes the
"ESC [ M a" is followed by a "ESC [ M #" and sometimes not.

I guess rather than map those lone "up-mouse" events to `mouse-1' we
should just drop them in the floor.

> C-x 3

OK.

> ESC [ M SPC \334 5
> ESC [ M # \334 5

That's a good down-mouse-1 + mouse-1 (at position 188,21)

> ESC [ M 5 ESC [

Hmm... this "5" is an unknown button code.
And it would be at position -5,59, which is not valid.

Can you try the following:

- do the C-x 3 dance to set up the windows in the problematic way.
- move your mouse to the problematic place.
- click mouse buttons 1, 2, 3, 4, 5 in this order (mouse-4 is
  "wheel-up") and all at the exact same position (i.e. without moving the
  mouse between the clicks).
- move the mouse a bit.
- click mouse buttons 1, 2, 3, 4, 5 again.
- show us the resulting view-lossage.

So we can try and guess what this weird "ESC [ M 5 ESC [" is about.


        Stefan