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

Package: emacs;

Reported by: Didier <didibus <at> gmail.com>

Date: Sun, 1 Aug 2021 02:29:02 UTC

Severity: normal

Tags: moreinfo

Found in version 27.2

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49803 in the body.
You can then email your comments to 49803 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Sun, 01 Aug 2021 02:29:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Didier <didibus <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 01 Aug 2021 02:29:02 GMT) Full text and rfc822 format available.

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

From: Didier <didibus <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 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: Sat, 31 Jul 2021 19:27:58 -0700
[Message part 1 (text/plain, inline)]
I'm on a MacBook Pro with macOS Big Sur, and on both the laptop trackpad
and with my plugged in USB mouse, the wheel or 2-finger up/down on
trackpad, is reported to Emacs when in terminal as mouse-4 and mouse-5.
That means that scroll doesn't work in Terminal.app or in iTerm2 on MAC,
since mouse-4 and mouse-5 are not bound.

In the GUI Mac it works, because it gets reported as wheel-up and
wheel-down.

My thought is maybe here
https://github.com/emacs-mirror/emacs/blob/master/lisp/mwheel.el#L54
there should be an additional check for if its running with a
window-system or not?


In GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
Version 10.14.6 (Build 18G95))
of 2021-03-27 built on builder10-14.porkrind.org
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.3.1
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Sun, 01 Aug 2021 06:19:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Didier <didibus <at> gmail.com>
Cc: 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: Sun, 01 Aug 2021 09:18:37 +0300
> From: Didier <didibus <at> gmail.com>
> Date: Sat, 31 Jul 2021 19:27:58 -0700
> 
> I'm on a MacBook Pro with macOS Big Sur, and on both the laptop trackpad
> and with my plugged in USB mouse, the wheel or 2-finger up/down on
> trackpad, is reported to Emacs when in terminal as mouse-4 and mouse-5.
> That means that scroll doesn't work in Terminal.app or in iTerm2 on MAC,
> since mouse-4 and mouse-5 are not bound.
> 
> In the GUI Mac it works, because it gets reported as wheel-up and
> wheel-down.
> 
> My thought is maybe here
> https://github.com/emacs-mirror/emacs/blob/master/lisp/mwheel.el#L54
> there should be an additional check for if its running with a
> window-system or not?

I don't think I follow.  The defcustoms there say:

  (defcustom mouse-wheel-down-event
    (if (or (featurep 'w32-win) (featurep 'ns-win))
	'wheel-up
      'mouse-4)
    "Event used for scrolling down."
    :group 'mouse
    :type 'symbol
    :set 'mouse-wheel-change-button)

  (defcustom mouse-wheel-up-event
    (if (or (featurep 'w32-win) (featurep 'ns-win))
	'wheel-down
      'mouse-5)
    "Event used for scrolling up."
    :group 'mouse
    :type 'symbol
    :set 'mouse-wheel-change-button)

This seems already to cater to macOS, so why isn't it working for you?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 02 Aug 2021 06:45:01 GMT) Full text and rfc822 format available.

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

From: Didier <didibus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 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: Sun, 1 Aug 2021 23:44:05 -0700
[Message part 1 (text/plain, inline)]
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.

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)

Does that make sense?

On Sat, 31 Jul 2021 at 23:18, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Didier <didibus <at> gmail.com>
> > Date: Sat, 31 Jul 2021 19:27:58 -0700
> >
> > I'm on a MacBook Pro with macOS Big Sur, and on both the laptop trackpad
> > and with my plugged in USB mouse, the wheel or 2-finger up/down on
> > trackpad, is reported to Emacs when in terminal as mouse-4 and mouse-5.
> > That means that scroll doesn't work in Terminal.app or in iTerm2 on MAC,
> > since mouse-4 and mouse-5 are not bound.
> >
> > In the GUI Mac it works, because it gets reported as wheel-up and
> > wheel-down.
> >
> > My thought is maybe here
> > https://github.com/emacs-mirror/emacs/blob/master/lisp/mwheel.el#L54
> > there should be an additional check for if its running with a
> > window-system or not?
>
> I don't think I follow.  The defcustoms there say:
>
>   (defcustom mouse-wheel-down-event
>     (if (or (featurep 'w32-win) (featurep 'ns-win))
>         'wheel-up
>       'mouse-4)
>     "Event used for scrolling down."
>     :group 'mouse
>     :type 'symbol
>     :set 'mouse-wheel-change-button)
>
>   (defcustom mouse-wheel-up-event
>     (if (or (featurep 'w32-win) (featurep 'ns-win))
>         'wheel-down
>       'mouse-5)
>     "Event used for scrolling up."
>     :group 'mouse
>     :type 'symbol
>     :set 'mouse-wheel-change-button)
>
> This seems already to cater to macOS, so why isn't it working for you?
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 02 Aug 2021 11:22:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Didier <didibus <at> gmail.com>
Cc: 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, 02 Aug 2021 14:21:38 +0300
> 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.
> 
> 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)

Did you try that?

The problem here is that the initial frame is not a GUI frame even in
a GUI session, so the defcustom could pick up the wrong value.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 09 Aug 2021 10:30:02 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Tue, 10 Aug 2021 12:45:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 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: Tue, 10 Aug 2021 15:44:44 +0300
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Didier <didibus <at> gmail.com>,  49803 <at> 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.

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

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Wed, 11 Aug 2021 09:26:02 GMT) Full text and rfc822 format available.

Message #23 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: 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: Wed, 11 Aug 2021 11:24:54 +0200
>>>>> On Tue, 10 Aug 2021 15:44:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: Didier <didibus <at> gmail.com>,  49803 <at> 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
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Wed, 11 Aug 2021 12:03:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 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: Wed, 11 Aug 2021 15:03:01 +0300
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: didibus <at> gmail.com,  49803 <at> debbugs.gnu.org
> Date: Wed, 11 Aug 2021 11:24:54 +0200
> 
> 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.

Does the xterm protocol allow to report wheel events, or does it only
allow to report mouse-click events?  If the latter, I don't see how
you could map the events in any way different from what we have now,
i.e. via a user-controlled setting.

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

The "GUI" part is not important in what I wrote, you can replace it
with "UI" or even with nothing.  I was talking about the APIs we use
to access the mouse events.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Wed, 11 Aug 2021 15:01:02 GMT) Full text and rfc822 format available.

Message #29 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: 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: Wed, 11 Aug 2021 16:59:45 +0200
>>>>> On Wed, 11 Aug 2021 15:03:01 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: didibus <at> gmail.com,  49803 <at> debbugs.gnu.org
    >> Date: Wed, 11 Aug 2021 11:24:54 +0200
    >> 
    >> 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.

    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'

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)

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Wed, 11 Aug 2021 16:42:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 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: Wed, 11 Aug 2021 19:41:27 +0300
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: didibus <at> gmail.com,  49803 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Wed, 11 Aug 2021 17:11:02 GMT) Full text and rfc822 format available.

Message #35 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: 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: Wed, 11 Aug 2021 19:10:51 +0200
>>>>> On Wed, 11 Aug 2021 19:41:27 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: didibus <at> gmail.com,  49803 <at> 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'

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

Absolutely

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

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

Something like this. We can discuss if xterm-mouse-map-buttons should
default to t on ns-win or not. I think it should, because then using
the mouse wheel with builtin and external trackpads becomes:

(require 'mwheel)
(require 'mouse)
(xterm-mouse-mode t)
(mouse-wheel-mode t)

with no other configuration required.

diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index 72faff8101..7906a6a024 100644
--- a/lisp/xt-mouse.el
+++ b/lisp/xt-mouse.el
@@ -42,6 +42,28 @@
 
 (defvar xterm-mouse-debug-buffer nil)
 
+(defcustom xterm-mouse-map-buttons
+  (if (featurep 'ns-win)
+      t
+    nil)
+  "Non-nil if xterm should perfom mouse button mappings.
+Will use `xterm-mouse-map-buttons-alist' for the mapping.
+Defaults to t when using macOS for consistency with 'mwheel'."
+  :type 'boolean
+  :version "28.1"
+  :group 'xterm)
+
+(defcustom xterm-mouse-map-buttons-alist
+  '((mouse-4 . wheel-up)
+    (mouse-5 . wheel-down))
+  "Alist used to map buttons to different buttons.
+Only consulted if `xterm-mouse-map-buttons' is non-nil.  The
+default value maps 'mouse-4' and 'mouse-5 to 'wheel-up' and
+'wheel-down'."
+  :type 'alist
+  :version "28.1"
+  :group 'xterm)
+
 (defun xterm-mouse-translate (_event)
   "Read a click and release event from XTerm."
   (xterm-mouse-translate-1))
@@ -65,8 +87,12 @@ xterm-mouse-translate-1
 
       ;; Mouse events symbols must have an 'event-kind property with
       ;; the value 'mouse-click.
-      (when ev-command (put ev-command 'event-kind 'mouse-click))
-
+      (when ev-command
+        (put ev-command 'event-kind 'mouse-click)
+        (when xterm-mouse-map-buttons
+          (when-let (mapping (alist-get ev-command xterm-mouse-map-buttons-alist))
+            (setq ev-command mapping)
+            (setf (nth 0 event) ev-command))))
       (cond
        ((null event) nil)		;Unknown/bogus byte sequence!
        (is-down

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Wed, 11 Aug 2021 17:39:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 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: Wed, 11 Aug 2021 20:38:18 +0300
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: didibus <at> gmail.com,  49803 <at> debbugs.gnu.org
> Date: Wed, 11 Aug 2021 19:10:51 +0200
> 
> Something like this. We can discuss if xterm-mouse-map-buttons should
> default to t on ns-win or not. I think it should, because then using
> the mouse wheel with builtin and external trackpads becomes:
> 
> (require 'mwheel)
> (require 'mouse)
> (xterm-mouse-mode t)
> (mouse-wheel-mode t)
> 
> with no other configuration required.
> 
> diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
> index 72faff8101..7906a6a024 100644
> --- a/lisp/xt-mouse.el
> +++ b/lisp/xt-mouse.el
> @@ -42,6 +42,28 @@
>  
>  (defvar xterm-mouse-debug-buffer nil)
>  
> +(defcustom xterm-mouse-map-buttons
> +  (if (featurep 'ns-win)
> +      t
> +    nil)
> +  "Non-nil if xterm should perfom mouse button mappings.
> +Will use `xterm-mouse-map-buttons-alist' for the mapping.
> +Defaults to t when using macOS for consistency with 'mwheel'."
> +  :type 'boolean
> +  :version "28.1"
> +  :group 'xterm)

So you are saying that by moving this from mwheel.el, we avoid the
danger of using the wrong mapping on TTY frames on macOS?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Thu, 12 Aug 2021 07:49:01 GMT) Full text and rfc822 format available.

Message #41 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: 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: Thu, 12 Aug 2021 09:48:18 +0200
>>>>> On Wed, 11 Aug 2021 20:38:18 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
    >> +(defcustom xterm-mouse-map-buttons
    >> +  (if (featurep 'ns-win)
    >> +      t
    >> +    nil)
    >> +  "Non-nil if xterm should perfom mouse button mappings.
    >> +Will use `xterm-mouse-map-buttons-alist' for the mapping.
    >> +Defaults to t when using macOS for consistency with 'mwheel'."
    >> +  :type 'boolean
    >> +  :version "28.1"
    >> +  :group 'xterm)

    Eli> So you are saying that by moving this from mwheel.el, we avoid the
    Eli> danger of using the wrong mapping on TTY frames on macOS?

With the caveat that weʼre not moving anything from mwheel, but rather
adapting xt-mouse to mwheel's expectations, yes. I think thatʼs a
better idea than adapting mwheel to have frame-specific values for
mouse-wheel-{up,down}-event.

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Thu, 12 Aug 2021 08:12:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 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: Thu, 12 Aug 2021 11:11:30 +0300
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: didibus <at> gmail.com,  49803 <at> debbugs.gnu.org
> Date: Thu, 12 Aug 2021 09:48:18 +0200
> 
> >>>>> On Wed, 11 Aug 2021 20:38:18 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>     >> +(defcustom xterm-mouse-map-buttons
>     >> +  (if (featurep 'ns-win)
>     >> +      t
>     >> +    nil)
>     >> +  "Non-nil if xterm should perfom mouse button mappings.
>     >> +Will use `xterm-mouse-map-buttons-alist' for the mapping.
>     >> +Defaults to t when using macOS for consistency with 'mwheel'."
>     >> +  :type 'boolean
>     >> +  :version "28.1"
>     >> +  :group 'xterm)
> 
>     Eli> So you are saying that by moving this from mwheel.el, we avoid the
>     Eli> danger of using the wrong mapping on TTY frames on macOS?
> 
> With the caveat that weʼre not moving anything from mwheel, but rather
> adapting xt-mouse to mwheel's expectations, yes. I think thatʼs a
> better idea than adapting mwheel to have frame-specific values for
> mouse-wheel-{up,down}-event.

I think you are right, assuming that xt-mouse is the only way macOS
terminals can support a mouse.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Thu, 12 Aug 2021 09:55:02 GMT) Full text and rfc822 format available.

Message #47 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: 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: Thu, 12 Aug 2021 11:54:47 +0200
>>>>> On Thu, 12 Aug 2021 11:11:30 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
    >> With the caveat that weʼre not moving anything from mwheel, but rather
    >> adapting xt-mouse to mwheel's expectations, yes. I think thatʼs a
    >> better idea than adapting mwheel to have frame-specific values for
    >> mouse-wheel-{up,down}-event.

    Eli> I think you are right, assuming that xt-mouse is the only way macOS
    Eli> terminals can support a mouse.

I donʼt know if itʼs the only way, but certainly the standard
Terminal.app and the quite popular iterm2 both work with
xt-mouse. Didier, would you know?

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 22 Aug 2022 10:39:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: didibus <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 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, 22 Aug 2022 12:38:44 +0200
Robert Pluim <rpluim <at> gmail.com> writes:

> Something like this. We can discuss if xterm-mouse-map-buttons should
> default to t on ns-win or not. I think it should, because then using
> the mouse wheel with builtin and external trackpads becomes:

This was a year ago, but the patch (which made sense to me, but I seldom
use Macos) wasn't applied.

Was this fixed a different way?




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 22 Aug 2022 10:39:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 22 Aug 2022 12:00:02 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: didibus <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 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, 22 Aug 2022 13:59:24 +0200
>>>>> On Mon, 22 Aug 2022 12:38:44 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> Robert Pluim <rpluim <at> gmail.com> writes:
    >> Something like this. We can discuss if xterm-mouse-map-buttons should
    >> default to t on ns-win or not. I think it should, because then using
    >> the mouse wheel with builtin and external trackpads becomes:

    Lars> This was a year ago, but the patch (which made sense to me, but I seldom
    Lars> use Macos) wasn't applied.

    Lars> Was this fixed a different way?

I donʼt think so. I donʼt use 'emacs -nw' on MacOS very much either.

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 22 Aug 2022 12:05:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: didibus <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 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, 22 Aug 2022 14:03:49 +0200
Robert Pluim <rpluim <at> gmail.com> writes:

>     Lars> Robert Pluim <rpluim <at> gmail.com> writes:
>     >> Something like this. We can discuss if xterm-mouse-map-buttons should
>     >> default to t on ns-win or not. I think it should, because then using
>     >> the mouse wheel with builtin and external trackpads becomes:
>
>     Lars> This was a year ago, but the patch (which made sense to me,
>     Lars> but I seldom
>     Lars> use Macos) wasn't applied.
>
>     Lars> Was this fixed a different way?
>
> I donʼt think so. I donʼt use 'emacs -nw' on MacOS very much either.

Me neither.  Should we push the patch and see whether anybody complains?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 22 Aug 2022 12:13:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: didibus <at> gmail.com, Robert Pluim <rpluim <at> gmail.com>, 49803 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> 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, 22 Aug 2022 20:12:01 +0800
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Robert Pluim <rpluim <at> gmail.com> writes:
>
>> Something like this. We can discuss if xterm-mouse-map-buttons should
>> default to t on ns-win or not. I think it should, because then using
>> the mouse wheel with builtin and external trackpads becomes:
>
> This was a year ago, but the patch (which made sense to me, but I seldom
> use Macos) wasn't applied.
>
> Was this fixed a different way?

See 133f9a7e940e9696d998284b264dfa6430932c3e.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 22 Aug 2022 12:15:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: didibus <at> gmail.com, Robert Pluim <rpluim <at> gmail.com>, 49803 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> 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, 22 Aug 2022 14:14:40 +0200
Po Lu <luangruo <at> yahoo.com> writes:

>> This was a year ago, but the patch (which made sense to me, but I seldom
>> use Macos) wasn't applied.
>>
>> Was this fixed a different way?
>
> See 133f9a7e940e9696d998284b264dfa6430932c3e.

Thanks; so I guess this bug report can be closed?  Done now.




bug marked as fixed in version 29.1, send any further explanations to 49803 <at> debbugs.gnu.org and Didier <didibus <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 22 Aug 2022 12:15:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49803; Package emacs. (Mon, 22 Aug 2022 13:16:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: didibus <at> gmail.com, Robert Pluim <rpluim <at> gmail.com>, 49803 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> 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, 22 Aug 2022 21:14:48 +0800
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Thanks; so I guess this bug report can be closed?  Done now.

Yeah, please go ahead and do that.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 20 Sep 2022 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 219 days ago.

Previous Next


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