GNU bug report logs - #68698
30.0.50; Making xt-mouse emit `wheel-up/down`

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Wed, 24 Jan 2024 20:34:02 UTC

Severity: normal

Found in version 30.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

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 68698 in the body.
You can then email your comments to 68698 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#68698; Package emacs. (Wed, 24 Jan 2024 20:34:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefan Monnier <monnier <at> iro.umontreal.ca>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 24 Jan 2024 20:34:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Wed, 24 Jan 2024 15:31:32 -0500
[Message part 1 (text/plain, inline)]
Package: Emacs
Version: 30.0.50


Currently, wheel-up/down events are generated in most setups instead
of the old mouse-4/5.  There are still two exceptions:
- X11 builds not using XInput2.
- text terminals.
The attached patch intends to fix the second bullet.
Text terminals themselves only give us info equivalent to `mouse-4/5`
and don't actually tell us that it's a wheel movement, but we can still
turn those things into `wheel-up/down`.

This is related to bug#49803.

The second step would be to do something similar for the non-XInput2 X11
build: make it generate `wheel-up/down` events according to
`mouse-wheel-down/up-event` settings.  Then packages like
`completion-preview` and `mwheel` won't need to pay attention to the
(confusingly named) `mouse-wheel-down/up-event` vars any more.


        Stefan
[xtmouse.patch (text/x-diff, inline)]
diff --git a/lisp/mwheel.el b/lisp/mwheel.el
index 53042085bf6..66a1fa1a706 100644
--- a/lisp/mwheel.el
+++ b/lisp/mwheel.el
@@ -59,7 +59,7 @@ mouse-wheel-change-button
 (defvar mouse-wheel-obey-old-style-wheel-buttons t
   "If non-nil, treat mouse-4/5/6/7 events as mouse wheel events.
 These are the event names used historically in X11 before XInput2.
-They are sometimes generated by things like `xterm-mouse-mode' as well.")
+They are sometimes generated by things like text-terminals as well.")
 
 (defcustom mouse-wheel-down-event
   (if mouse-wheel-obey-old-style-wheel-buttons 'mouse-4)
diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index cd00467f14f..fcc0db1d9eb 100644
--- a/lisp/xt-mouse.el
+++ b/lisp/xt-mouse.el
@@ -40,6 +40,8 @@
 
 ;;; Code:
 
+(require 'mwheel)
+
 (defvar xterm-mouse-debug-buffer nil)
 
 (defun xterm-mouse-translate (_event)
@@ -193,6 +195,12 @@ xterm-mouse--read-number-from-terminal
           (cons n c))
       (cons (- (setq c (xterm-mouse--read-coordinate)) 32) c))))
 
+(defun xterm-mouse--same-button-p (event btn)
+  (and (symbolp event)
+       (string-prefix-p "mouse-" (symbol-name event))
+       (eq btn (car (read-from-string (symbol-name event)
+                                      (length "mouse-"))))))
+
 ;; XTerm reports mouse events as
 ;; <EVENT-CODE> <X> <Y> in default mode, and
 ;; <EVENT-CODE> ";" <X> ";" <Y> <"M" or "m"> in extended mode.
@@ -231,12 +239,24 @@ xterm-mouse--read-event-sequence
              ;; event: assume, that the last button was button 1.
              (t 1)))
        (sym (if move 'mouse-movement
-              (intern (concat (if ctrl "C-" "")
-                              (if meta "M-" "")
-                              (if shift "S-" "")
-                              (if down "down-" "")
-                              "mouse-"
-                              (number-to-string btn))))))
+             (intern
+              (concat
+               (if ctrl "C-" "")
+               (if meta "M-" "")
+               (if shift "S-" "")
+               (if down "down-" "")
+               (cond
+                ;; BEWARE: `mouse-wheel-UP-event' corresponds to
+                ;; `wheel-DOWN' events and vice versa!!
+                ((xterm-mouse--same-button-p mouse-wheel-down-event btn)
+                 "wheel-up")
+                ((xterm-mouse--same-button-p mouse-wheel-up-event btn)
+                 "wheel-down")
+                ((xterm-mouse--same-button-p mouse-wheel-left-event btn)
+                 "wheel-left")
+                ((xterm-mouse--same-button-p mouse-wheel-right-event btn)
+                 "wheel-right")
+                (t (format "mouse-%d" btn))))))))
     (list sym (1- x) (1- y))))
 
 (defun xterm-mouse--set-click-count (event click-count)

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Thu, 25 Jan 2024 02:27:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 10:25:53 +0800
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> The second step would be to do something similar for the non-XInput2 X11
> build: make it generate `wheel-up/down` events according to
> `mouse-wheel-down/up-event` settings.  Then packages like
> `completion-preview` and `mwheel` won't need to pay attention to the
> (confusingly named) `mouse-wheel-down/up-event` vars any more.

No!

Button4, 5, 6 and 7 are only mouse wheels in one particular group of X
servers.  It is impossible to detect whether they are mouse wheels
without the input extension (and this is why XI display connections
produce wheel events), so such an escape hatch as mouse-wheel-*-event
_must_ be provided for X servers where the general assumption that they
are mouse wheels does not hold true.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Thu, 25 Jan 2024 07:31:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Jared Finder <jared <at> finder.org>
Cc: 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 09:30:05 +0200
> Date: Wed, 24 Jan 2024 15:31:32 -0500
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Package: Emacs
> Version: 30.0.50
> 
> 
> Currently, wheel-up/down events are generated in most setups instead
> of the old mouse-4/5.  There are still two exceptions:
> - X11 builds not using XInput2.
> - text terminals.
> The attached patch intends to fix the second bullet.
> Text terminals themselves only give us info equivalent to `mouse-4/5`
> and don't actually tell us that it's a wheel movement, but we can still
> turn those things into `wheel-up/down`.
> 
> This is related to bug#49803.

Jared, any comments on the patch, or related issues?

Thanks.

> The second step would be to do something similar for the non-XInput2 X11
> build: make it generate `wheel-up/down` events according to
> `mouse-wheel-down/up-event` settings.  Then packages like
> `completion-preview` and `mwheel` won't need to pay attention to the
> (confusingly named) `mouse-wheel-down/up-event` vars any more.
> 
> 
>         Stefan
> 
> diff --git a/lisp/mwheel.el b/lisp/mwheel.el
> index 53042085bf6..66a1fa1a706 100644
> --- a/lisp/mwheel.el
> +++ b/lisp/mwheel.el
> @@ -59,7 +59,7 @@ mouse-wheel-change-button
>  (defvar mouse-wheel-obey-old-style-wheel-buttons t
>    "If non-nil, treat mouse-4/5/6/7 events as mouse wheel events.
>  These are the event names used historically in X11 before XInput2.
> -They are sometimes generated by things like `xterm-mouse-mode' as well.")
> +They are sometimes generated by things like text-terminals as well.")
>  
>  (defcustom mouse-wheel-down-event
>    (if mouse-wheel-obey-old-style-wheel-buttons 'mouse-4)
> diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
> index cd00467f14f..fcc0db1d9eb 100644
> --- a/lisp/xt-mouse.el
> +++ b/lisp/xt-mouse.el
> @@ -40,6 +40,8 @@
>  
>  ;;; Code:
>  
> +(require 'mwheel)
> +
>  (defvar xterm-mouse-debug-buffer nil)
>  
>  (defun xterm-mouse-translate (_event)
> @@ -193,6 +195,12 @@ xterm-mouse--read-number-from-terminal
>            (cons n c))
>        (cons (- (setq c (xterm-mouse--read-coordinate)) 32) c))))
>  
> +(defun xterm-mouse--same-button-p (event btn)
> +  (and (symbolp event)
> +       (string-prefix-p "mouse-" (symbol-name event))
> +       (eq btn (car (read-from-string (symbol-name event)
> +                                      (length "mouse-"))))))
> +
>  ;; XTerm reports mouse events as
>  ;; <EVENT-CODE> <X> <Y> in default mode, and
>  ;; <EVENT-CODE> ";" <X> ";" <Y> <"M" or "m"> in extended mode.
> @@ -231,12 +239,24 @@ xterm-mouse--read-event-sequence
>               ;; event: assume, that the last button was button 1.
>               (t 1)))
>         (sym (if move 'mouse-movement
> -              (intern (concat (if ctrl "C-" "")
> -                              (if meta "M-" "")
> -                              (if shift "S-" "")
> -                              (if down "down-" "")
> -                              "mouse-"
> -                              (number-to-string btn))))))
> +             (intern
> +              (concat
> +               (if ctrl "C-" "")
> +               (if meta "M-" "")
> +               (if shift "S-" "")
> +               (if down "down-" "")
> +               (cond
> +                ;; BEWARE: `mouse-wheel-UP-event' corresponds to
> +                ;; `wheel-DOWN' events and vice versa!!
> +                ((xterm-mouse--same-button-p mouse-wheel-down-event btn)
> +                 "wheel-up")
> +                ((xterm-mouse--same-button-p mouse-wheel-up-event btn)
> +                 "wheel-down")
> +                ((xterm-mouse--same-button-p mouse-wheel-left-event btn)
> +                 "wheel-left")
> +                ((xterm-mouse--same-button-p mouse-wheel-right-event btn)
> +                 "wheel-right")
> +                (t (format "mouse-%d" btn))))))))
>      (list sym (1- x) (1- y))))
>  
>  (defun xterm-mouse--set-click-count (event click-count)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Thu, 25 Jan 2024 13:48:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 08:47:17 -0500
Po Lu [2024-01-25 10:25:53] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> The second step would be to do something similar for the non-XInput2 X11
>> build: make it generate `wheel-up/down` events according to
>> `mouse-wheel-down/up-event` settings.  Then packages like
>> `completion-preview` and `mwheel` won't need to pay attention to the
>> (confusingly named) `mouse-wheel-down/up-event` vars any more.
>
> No!
>
> Button4, 5, 6 and 7 are only mouse wheels in one particular group of X
> servers.  It is impossible to detect whether they are mouse wheels
> without the input extension (and this is why XI display connections
> produce wheel events), so such an escape hatch as mouse-wheel-*-event
> _must_ be provided for X servers where the general assumption that they
> are mouse wheels does not hold true.

I'm not suggesting to get rid of those vars.  I'm suggesting to use
those vars in the C code when generating the event.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Thu, 25 Jan 2024 14:18:01 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 22:16:54 +0800
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I'm not suggesting to get rid of those vars.  I'm suggesting to use
> those vars in the C code when generating the event.

Why, though?  Why not bind them within input-decode-map, if really
necessary?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Thu, 25 Jan 2024 15:42:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 10:41:03 -0500
Po Lu [2024-01-25 22:16:54] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I'm not suggesting to get rid of those vars.  I'm suggesting to use
>> those vars in the C code when generating the event.
> Why, though?  Why not bind them within input-decode-map, if really
> necessary?

The main reason is that it's painful to do it in `input-decode-map`
because it has to be done not just for `mouse-4/5/6/7` but for all
combinations of possible modifiers (shift, control, alt, meta, super,
hyper, double, triple, down), so that's like a couple thousand entries
we'd need to put in that map.


        Stefan "wishing we had more flexible keymaps (e.g. "procedural"
                keymaps which can compute the binding for a given key)"





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Fri, 26 Jan 2024 01:42:02 GMT) Full text and rfc822 format available.

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

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68698 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 17:41:20 -0800
On 2024-01-24 23:30, Eli Zaretskii wrote:
>> Date: Wed, 24 Jan 2024 15:31:32 -0500
>> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Package: Emacs
>> Version: 30.0.50
>> 
>> 
>> Currently, wheel-up/down events are generated in most setups instead
>> of the old mouse-4/5.  There are still two exceptions:
>> - X11 builds not using XInput2.
>> - text terminals.
>> The attached patch intends to fix the second bullet.
>> Text terminals themselves only give us info equivalent to `mouse-4/5`
>> and don't actually tell us that it's a wheel movement, but we can 
>> still
>> turn those things into `wheel-up/down`.
>> 
>> This is related to bug#49803.
> 
> Jared, any comments on the patch, or related issues?
> 
> Thanks.
> 
>> The second step would be to do something similar for the non-XInput2 
>> X11
>> build: make it generate `wheel-up/down` events according to
>> `mouse-wheel-down/up-event` settings.  Then packages like
>> `completion-preview` and `mwheel` won't need to pay attention to the
>> (confusingly named) `mouse-wheel-down/up-event` vars any more.

I'll be so happy if everything switches over to mouse-up / mouse-down 
events.  This would be great.  I'd love to ignore mouse-wheel-down-event 
and mouse-wheel-down-alternate-event.

>> diff --git a/lisp/mwheel.el b/lisp/mwheel.el
>> @@ -231,12 +239,24 @@ xterm-mouse--read-event-sequence
>>               ;; event: assume, that the last button was button 1.
>>               (t 1)))
>>         (sym (if move 'mouse-movement
>> -              (intern (concat (if ctrl "C-" "")
>> -                              (if meta "M-" "")
>> -                              (if shift "S-" "")
>> -                              (if down "down-" "")
>> -                              "mouse-"
>> -                              (number-to-string btn))))))
>> +             (intern
>> +              (concat
>> +               (if ctrl "C-" "")
>> +               (if meta "M-" "")
>> +               (if shift "S-" "")
>> +               (if down "down-" "")
>> +               (cond
>> +                ;; BEWARE: `mouse-wheel-UP-event' corresponds to
>> +                ;; `wheel-DOWN' events and vice versa!!
>> +                ((xterm-mouse--same-button-p mouse-wheel-down-event 
>> btn)
>> +                 "wheel-up")
>> +                ((xterm-mouse--same-button-p mouse-wheel-up-event 
>> btn)
>> +                 "wheel-down")
>> +                ((xterm-mouse--same-button-p mouse-wheel-left-event 
>> btn)
>> +                 "wheel-left")
>> +                ((xterm-mouse--same-button-p mouse-wheel-right-event 
>> btn)
>> +                 "wheel-right")

I think there is a bug with mouse-wheel-up/down/left/right-event and 
alternate event where it doesn't take window-system into account.  
Without fixing that bug, this won't work because it is valid for 
mouse-wheel-up-event to be wheel-down in a terminal.  A local run of 
HEAD (as of Jan 17, I'm at daec3e) with "./configure --with-pgtk" has 
mouse-wheel-up-event set to wheel-down because (featurep 'pgtk-win) is 
t, even with -nw on the command line.  Testing on Windows at Emacs 29.1 
shows the same behavior.

Also, I do not think xt-mouse knows how to generate mouse-6 or mouse-7 
events.  I think to generate events beyond mouse-5, you need to test 
against the 128 bit as well.  I don't have mouse hardware to confirm 
this behavior.

  -- MJF




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Fri, 26 Jan 2024 02:01:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Fri, 26 Jan 2024 09:59:50 +0800
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> The main reason is that it's painful to do it in `input-decode-map`
> because it has to be done not just for `mouse-4/5/6/7` but for all
> combinations of possible modifiers (shift, control, alt, meta, super,
> hyper, double, triple, down), so that's like a couple thousand entries
> we'd need to put in that map.

I am quite loath to change the set of events generated by the X11 button
event processing code, in view of the convoluted interaction between it,
toolkits, and code further down the line.  Any other solution would be
preferable, such as perhaps:

>         Stefan "wishing we had more flexible keymaps (e.g. "procedural"
>                 keymaps which can compute the binding for a given key)"




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Fri, 26 Jan 2024 02:28:03 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jared Finder <jared <at> finder.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 21:26:49 -0500
> A local run of HEAD (as of Jan 17, I'm at daec3e) with
> "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
> because (featurep 'pgtk-win) is t, even with -nw on the command line.
> Testing on Windows at Emacs 29.1 shows the same behavior.

This has been changed on `master` around Jan 19.  Now `mwheel.el` uses
`wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
used for *other* events (defaults to `mouse-4/5`).

> Also, I do not think xt-mouse knows how to generate mouse-6 or mouse-7
> events.  I think to generate events beyond mouse-5, you need to test
> against the 128 bit as well.  I don't have mouse hardware to confirm
> this behavior.

I didn't both to check the code to see if that can happen (especially
since there are various possible encodings coming from the terminal).
The way wrote the code, it'll do the right thing if/when the rest of
`xt-mouse` manages to generate those events, but indeed it might be the
case that currently this will never happen.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Fri, 26 Jan 2024 02:31:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 21:30:02 -0500
Po Lu [2024-01-26 09:59:50] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> The main reason is that it's painful to do it in `input-decode-map`
>> because it has to be done not just for `mouse-4/5/6/7` but for all
>> combinations of possible modifiers (shift, control, alt, meta, super,
>> hyper, double, triple, down), so that's like a couple thousand entries
>> we'd need to put in that map.
>
> I am quite loath to change the set of events generated by the X11 button
> event processing code, in view of the convoluted interaction between it,
> toolkits, and code further down the line.  Any other solution would be
> preferable, such as perhaps:

OK, will keep this in mind.  The current bug#68698 is only suggesting
changing `xt-mouse.el`, tho, so we can leave the X11 case for later (or
for never, since we may also decide to let it disappear into the past
as XInput2 becomes the norm).


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Fri, 26 Jan 2024 05:03:02 GMT) Full text and rfc822 format available.

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

From: Jared Finder <jared <at> finder.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 68698 <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Thu, 25 Jan 2024 21:02:34 -0800
On 2024-01-25 18:26, Stefan Monnier wrote:
>> A local run of HEAD (as of Jan 17, I'm at daec3e) with
>> "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
>> because (featurep 'pgtk-win) is t, even with -nw on the command line.
>> Testing on Windows at Emacs 29.1 shows the same behavior.
> 
> This has been changed on `master` around Jan 19.  Now `mwheel.el` uses
> `wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
> used for *other* events (defaults to `mouse-4/5`).
> 
>> Also, I do not think xt-mouse knows how to generate mouse-6 or mouse-7
>> events.  I think to generate events beyond mouse-5, you need to test
>> against the 128 bit as well.  I don't have mouse hardware to confirm
>> this behavior.
> 
> I didn't both to check the code to see if that can happen (especially
> since there are various possible encodings coming from the terminal).
> The way wrote the code, it'll do the right thing if/when the rest of
> `xt-mouse` manages to generate those events, but indeed it might be the
> case that currently this will never happen.

Ah great!

Then I have no concerns about this patch.

  -- MJF




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Fri, 26 Jan 2024 07:57:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68698 <at> debbugs.gnu.org, jared <at> finder.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Fri, 26 Jan 2024 09:56:23 +0200
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  68698 <at> debbugs.gnu.org
> Date: Thu, 25 Jan 2024 21:26:49 -0500
> 
> > A local run of HEAD (as of Jan 17, I'm at daec3e) with
> > "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
> > because (featurep 'pgtk-win) is t, even with -nw on the command line.
> > Testing on Windows at Emacs 29.1 shows the same behavior.
> 
> This has been changed on `master` around Jan 19.  Now `mwheel.el` uses
> `wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
> used for *other* events (defaults to `mouse-4/5`).

Was this reflected in the documentation?  The ELisp Reference manual
still says

     The ‘wheel-up’ and ‘wheel-down’ events are generated only on some
     kinds of systems.  On other systems, other events like ‘mouse-4’
     and ‘mouse-5’ are used instead.  Portable code should handle both
     ‘wheel-up’ and ‘wheel-down’ events as well as the events specified
     in the variables ‘mouse-wheel-up-event’ and
     ‘mouse-wheel-down-event’, defined in ‘mwheel.el’.  Beware that for
     historical reasons the ‘mouse-wheel-_up_-event’ is the variable
     that holds an event that should be handled similarly to
     ‘wheel-_down_’ and vice versa.

Is that still correct and accurate?  (And what about a similar issue
with wheel-left/right?).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#68698; Package emacs. (Fri, 26 Jan 2024 13:05:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68698 <at> debbugs.gnu.org, jared <at> finder.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Fri, 26 Jan 2024 08:04:17 -0500
>> > A local run of HEAD (as of Jan 17, I'm at daec3e) with
>> > "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
>> > because (featurep 'pgtk-win) is t, even with -nw on the command line.
>> > Testing on Windows at Emacs 29.1 shows the same behavior.
>> 
>> This has been changed on `master` around Jan 19.  Now `mwheel.el` uses
>> `wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
>> used for *other* events (defaults to `mouse-4/5`).
>
> Was this reflected in the documentation?  The ELisp Reference manual
> still says
>
>      The ‘wheel-up’ and ‘wheel-down’ events are generated only on some
>      kinds of systems.  On other systems, other events like ‘mouse-4’
>      and ‘mouse-5’ are used instead.  Portable code should handle both
>      ‘wheel-up’ and ‘wheel-down’ events as well as the events specified
>      in the variables ‘mouse-wheel-up-event’ and
>      ‘mouse-wheel-down-event’, defined in ‘mwheel.el’.  Beware that for
>      historical reasons the ‘mouse-wheel-_up_-event’ is the variable
>      that holds an event that should be handled similarly to
>      ‘wheel-_down_’ and vice versa.
>
> Is that still correct and accurate?  (And what about a similar issue
> with wheel-left/right?).

Yup, before Jan 19 the text was different :-)


        Stefan





Reply sent to Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility. (Sun, 28 Jan 2024 23:53:02 GMT) Full text and rfc822 format available.

Notification sent to Stefan Monnier <monnier <at> iro.umontreal.ca>:
bug acknowledged by developer. (Sun, 28 Jan 2024 23:53:02 GMT) Full text and rfc822 format available.

Message #46 received at 68698-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 68698-done <at> debbugs.gnu.org
Subject: Re: bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
Date: Sun, 28 Jan 2024 18:52:02 -0500
Pushed to `master`, closing,


        Stefan





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 26 Feb 2024 12:24:16 GMT) Full text and rfc822 format available.

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

Previous Next


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