bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

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

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xtmouse.patch --]
[-- Type: text/x-diff, Size: 2782 bytes --]

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)

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

Stefan Monnier <monnier@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.

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

[Eli Zaretskii]

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

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

Po Lu [2024-01-25 10:25:53] wrote:
> Stefan Monnier <monnier@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

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

Stefan Monnier <monnier@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?

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

Po Lu [2024-01-25 22:16:54] wrote:
> Stefan Monnier <monnier@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)"

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

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

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

Stefan Monnier <monnier@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)"

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

> 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

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

Po Lu [2024-01-26 09:59:50] wrote:
> Stefan Monnier <monnier@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

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

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

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  68698@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?).

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

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

bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`

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

Pushed to `master`, closing,


        Stefan