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

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

[Didier]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 11290 bytes --]

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: Didier <didibus@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?

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

[Didier]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

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@gnu.org> wrote:

> > From: Didier <didibus@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?
>

[-- Attachment #2: Type: text/html, Size: 2875 bytes --]

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: Didier <didibus@gmail.com>
> Date: Sun, 1 Aug 2021 23:44:05 -0700
> Cc: 49803@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.

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 Mon, 02 Aug 2021 14:21:38 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Didier <didibus@gmail.com>
    >> Date: Sun, 1 Aug 2021 23:44:05 -0700
    >> Cc: 49803@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
-- 

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

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.

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

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

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 Wed, 11 Aug 2021 15:03:01 +0300, Eli Zaretskii <eliz@gnu.org> said:

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

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?

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 Wed, 11 Aug 2021 19:41:27 +0300, Eli Zaretskii <eliz@gnu.org> said:

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

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

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

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 Wed, 11 Aug 2021 20:38:18 +0300, Eli Zaretskii <eliz@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
-- 

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: Thu, 12 Aug 2021 09:48:18 +0200
> 
> >>>>> On Wed, 11 Aug 2021 20:38:18 +0300, Eli Zaretskii <eliz@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.

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 Thu, 12 Aug 2021 11:11:30 +0300, Eli Zaretskii <eliz@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
-- 

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

[Lars Ingebrigtsen]

Robert Pluim <rpluim@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?

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 Mon, 22 Aug 2022 12:38:44 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@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
-- 

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

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>     Lars> Robert Pluim <rpluim@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?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@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.

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

[Lars Ingebrigtsen]

Po Lu <luangruo@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#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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

Yeah, please go ahead and do that.