all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
@ 2024-01-24 20:31 Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-25  2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-24 20:31 UTC (permalink / raw)
  To: 68698

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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-24 20:31 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
@ 2024-01-25  2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-25 13:47   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-25  7:30 ` Eli Zaretskii
  2024-01-28 23:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 1 reply; 14+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-25  2:25 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 68698

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-24 20:31 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
  2024-01-25  2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-25  7:30 ` Eli Zaretskii
  2024-01-26  1:41   ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-28 23:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2024-01-25  7:30 UTC (permalink / raw)
  To: Stefan Monnier, Jared Finder; +Cc: 68698

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-25  2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-25 13:47   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-25 14:16     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-25 13:47 UTC (permalink / raw)
  To: Po Lu; +Cc: 68698

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-25 13:47   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-25 14:16     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-25 15:41       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 14+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-25 14:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 68698

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?





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-25 14:16     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-25 15:41       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-26  1:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-25 15:41 UTC (permalink / raw)
  To: Po Lu; +Cc: 68698

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-25  7:30 ` Eli Zaretskii
@ 2024-01-26  1:41   ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-26  2:26     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 14+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-26  1:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 68698, Stefan Monnier

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-25 15:41       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-26  1:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-26  2:30           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 14+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-26  1:59 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 68698

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-26  1:41   ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-26  2:26     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-26  5:02       ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-26  7:56       ` Eli Zaretskii
  0 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-26  2:26 UTC (permalink / raw)
  To: Jared Finder; +Cc: Eli Zaretskii, 68698

> 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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-26  1:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-26  2:30           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-26  2:30 UTC (permalink / raw)
  To: Po Lu; +Cc: 68698

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-26  2:26     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-26  5:02       ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-26  7:56       ` Eli Zaretskii
  1 sibling, 0 replies; 14+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-26  5:02 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, 68698

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-26  2:26     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-26  5:02       ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-26  7:56       ` Eli Zaretskii
  2024-01-26 13:04         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2024-01-26  7:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 68698, jared

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-26  7:56       ` Eli Zaretskii
@ 2024-01-26 13:04         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-26 13:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 68698, jared

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#68698: 30.0.50; Making xt-mouse emit `wheel-up/down`
  2024-01-24 20:31 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
  2024-01-25  2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-01-25  7:30 ` Eli Zaretskii
@ 2024-01-28 23:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-28 23:52 UTC (permalink / raw)
  To: 68698-done

Pushed to `master`, closing,


        Stefan






^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2024-01-28 23:52 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-24 20:31 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
2024-01-25  2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 13:47   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 14:16     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 15:41       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26  1:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26  2:30           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25  7:30 ` Eli Zaretskii
2024-01-26  1:41   ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26  2:26     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26  5:02       ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26  7:56       ` Eli Zaretskii
2024-01-26 13:04         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 23:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.