bug#49803: 27.2; Mouse wheel on MacOS is reported as mouse-4 and mouse-5, but Emacs mwheel seems to use wheel-up/wheel-down instead

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: didibus@gmail.com,  49803@debbugs.gnu.org
> Date: Wed, 11 Aug 2021 16:59:45 +0200
> 
>     Eli> Does the xterm protocol allow to report wheel events, or does it only
>     Eli> allow to report mouse-click events?  If the latter, I don't see how
>     Eli> you could map the events in any way different from what we have now,
>     Eli> i.e. via a user-controlled setting.
> 
> It allows reporting wheel events, but as that part of the protocol is
> not being used by the iterm2 everything is reported as mouse clicks,
> but thatʼs immaterial:
> 
> - terminal sends "\e[<" to indicate itʼs sending us a mouse event
> - xt-mouse.el reads and decodes a bunch of stuff from the terminal
> - xt-mouse.el produces a 'mouse-<n>' event from that bunch of stuff, and
>   pushes it onto 'unread-command-events'

But then any mapping of mouse-4 etc. to wheel events is pure
heuristics, right?  There are mice out there which have more than 3
buttons, and they can legitimately produce mouse-4 for the 4th button,
right?

> So the only place I can see to add the optional mapping is in xt-mouse.el
> itself, or in 'read-char' in keyboard.c
> 
> Itʼs easier to do in xt-mouse.el, and as far as I can tell thatʼs the
> only terminal mouse handling code that does this kind of thing (GPM is
> handled in keyboard.c)

If I'm right, and this mapping is based on heuristics, we cannot
hard-code it, we must allow users to control the mapping in case the
heuristics fails.  Or am I missing something?