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

[Robert Pluim]

>>>>> On Tue, 10 Aug 2021 15:44:44 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Didier <didibus@gmail.com>,  49803@debbugs.gnu.org
    >> Date: Mon, 09 Aug 2021 12:29:32 +0200
    >> 
    >> >> So I think it should be modified to something like:
    >> >> 
    >> >> (if (or (featurep 'w32-win) (and (display-graphic-p) (featurep 
'ns-win)))
    >> >> 'wheel-down
    >> >> 'mouse-5)
    >> 
    Eli> Did you try that?
    >> 
    Eli> The problem here is that the initial frame is not a GUI frame even in
    Eli> a GUI session, so the defcustom could pick up the wrong value.
    >> 
    >> If we knew where and how the events were being received by emacs we
    >> could map them to wheel-{up,down}, but Iʼve not succeeded there.

    Eli> Where were you looking?  These events are formatted into Lisp in
    Eli> keyboard.c; search for "wheel-".

I was unclear: I hadn't figured out how to get the relevant terminal
programs to generate either wheel-up/down or mouse-4/5. It looks like
iterm2 sends mouse events using the xterm protocol, which xt-mouse
then posts as mouse-4/5 events. I guess we could modify xt-mouse to
optionally send them as wheel-up/down instead, but that feels like a hack.

Do we have a generic mapping mechanism for mouse events? I guess
theyʼre not keys, so keyboard-translate won't work.

    Eli> I guess the difference is between systems where the GUI API tells us
    Eli> explicitly whether its a wheel-up/down event, and systems where we
    Eli> just get "button number N" event.  Or something like that.

This is using emacs -nw, so the gui api is not involved.

Robert
--