GNU bug report logs - #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

Previous Next

Full log

Message #17 received at 49803 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Didier <didibus <at> gmail.com>, 49803 <at> debbugs.gnu.org
Subject: Re: 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
Date: Mon, 09 Aug 2021 12:29:32 +0200

>>>>> On Mon, 02 Aug 2021 14:21:38 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Didier <didibus <at> gmail.com>
    >> Date: Sun, 1 Aug 2021 23:44:05 -0700
    >> Cc: 49803 <at> debbugs.gnu.org
    >> 
    >> In macOS, when running Emacs in GUI, the wheel is received as <wheel-up> and <wheel-down> and it all
    >> works.
    >> 
    >> But in macOS, when running inside a terminal such as Terminal.app or iTerm2, the wheel is received as
    >> <mouse-4> and <mouse-5> and it no longer works, because the defcustom is not smart enough to check if
    >> we are running in GUI or not.
    >>

Hmm, I receive those as 'up' and 'down' in Terminal.app. And in iTerm2
Emacs doesnʼt receive them at all, even with 'mouse event reporting'
turned on. Does it depend on the configured terminal type?

    >> 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.

Robert
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.