GNU bug report logs - #51891
29.0.50; [PATCH] Pixel delta support for wheel events on X

Previous Next

Package: emacs;

Reported by: Po Lu <luangruo <at> yahoo.com>

Date: Tue, 16 Nov 2021 12:39:01 UTC

Severity: normal

Tags: patch

Found in version 29.0.50

Done: Po Lu <luangruo <at> yahoo.com>

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 51891 in the body.
You can then email your comments to 51891 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#51891; Package emacs. (Tue, 16 Nov 2021 12:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Po Lu <luangruo <at> yahoo.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 16 Nov 2021 12:39:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Pixel delta support for wheel events on X
Date: Tue, 16 Nov 2021 20:38:03 +0800
[Message part 1 (text/plain, inline)]
I've implemented support for exposing the pixel delta of XInput 2 wheel
events to Lisp code.  With GC turned off, utilizing a modified
pixel-scroll.el with this support results in a quite pleasant
experience, but pixel-scroll still GCs too much to be useful.

Pixel based scrolling is a popular feature in modern X applications, and
does make life a lot easier in many cases.  The existing support is
inadequate as it cannot utilize the detailed delta information available
from modern touch-based scroll wheels, which this patch enables.

The XInput 2 support isn't the best from a code duplication POV, but the
behavior of the XInput 2 code often differs in subtle ways from that of
the Core Input code, and trying to combine the two together would result
in a more catastrophic mess than leaving them apart.

Obviously, here is the original XInput 2 support patch:
[0001-Add-support-for-event-processing-via-XInput-2.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
And here is the patch that exposes pixel deltas to Lisp:
[0002-Expose-pixel-wise-wheel-events-to-Lisp.patch (text/x-patch, attachment)]
[Message part 5 (text/plain, inline)]
WDYT?  Thanks.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Tue, 16 Nov 2021 13:41:01 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: 51891 <at> debbugs.gnu.org
Cc: Po Lu <luangruo <at> yahoo.com>
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Tue, 16 Nov 2021 14:39:56 +0100
>>>>> On Tue, 16 Nov 2021 20:38:03 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:
    Po> +occurred.  The event may have additional arguments after
    Po> +@var{position}.  The third argument after @var{position}, if present,
    Po> +is a property list of the form @w{@code{(:delta-x @var{x} :delta-y
    Po> +@var{y})}}, where @var{x} and @var{y} are the number of pixels to
    Po> +scroll by in each axis.

Is there really a need for this to be a plist with :delta-x and
:delta-y in it? Just a cons of x and y would work.

    Po>  @vindex mouse-wheel-up-event
    Po>  @vindex mouse-wheel-down-event
    Po> diff --git a/src/keyboard.c b/src/keyboard.c
    Po> index de9805df32..276fd8c5aa 100644
    Po> --- a/src/keyboard.c
    Po> +++ b/src/keyboard.c
    Po> @@ -5980,7 +5980,10 @@ make_lispy_event (struct input_event *event)
    Po>  				      ASIZE (wheel_syms));
    Po>  	}
 
    Po> -        if (NUMBERP (event->arg))
    Po> +	if (CONSP (event->arg))
    Po> +	  return list5 (head, position, make_fixnum (double_click_count),
    Po> +			XCAR (event->arg), XCDR (event->arg));
    Po> +        else if (NUMBERP (event->arg))
    Po>            return list4 (head, position, make_fixnum (double_click_count),
    event-> arg);
    Po>  	else if (event->modifiers & (double_modifier | triple_modifier))
    Po> diff --git a/src/termhooks.h b/src/termhooks.h
    Po> index e7539bbce2..43a9fc2f22 100644
    Po> --- a/src/termhooks.h
    Po> +++ b/src/termhooks.h
    Po> @@ -119,7 +119,12 @@ #define EMACS_TERMHOOKS_H
    Po>  				   .timestamp gives a timestamp (in
    Po>  				   milliseconds) for the event.
    Po>                                     .arg may contain the number of
    Po> -                                   lines to scroll.  */
    Po> +                                   lines to scroll, or a list of
    Po> +				   the form (NUMBER-OF-LINES .
    Po> +				   (:DELTA-X :DELTA-Y Y)) where
    Po> +				   DELTA-X and DELTA-Y are the number
    Po> +				   of pixels on each axis to scroll
    Po> +				   by.  */

I donʼt think this is quite right. The 'X' is missing, and itʼs 'X'
and 'Y' that give the number of pixels. And :delta-x and :delta-y
(lowercase).

    Po>    HORIZ_WHEEL_EVENT,            /* A wheel event generated by a second
    Po>                                     horizontal wheel that is present on some
    Po>                                     mice. See WHEEL_EVENT.  */
    Po> diff --git a/src/xfns.c b/src/xfns.c
    Po> index b33b40b330..9d70ba479b 100644
    Po> --- a/src/xfns.c
    Po> +++ b/src/xfns.c
    Po> @@ -8085,6 +8085,9 @@ syms_of_xfns (void)
 
    Po>  #ifdef HAVE_XINPUT2
    Po>    DEFSYM (Qxinput2, "xinput2");
    Po> +  DEFSYM (QCdelta_x, ":delta-x");
    Po> +  DEFSYM (QCdelta_y, ":delta-y");
    Po> +
    Po>    Fprovide (Qxinput2, Qnil);
    Po>  #endif
 
    Po> diff --git a/src/xterm.c b/src/xterm.c
    Po> index 63754a2cb6..6eb361efca 100644
    Po> --- a/src/xterm.c
    Po> +++ b/src/xterm.c
    Po> @@ -9935,7 +9935,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
    Po>  		    block_input ();
 
    Po>  		    struct xi_scroll_valuator_t *val;
    Po> -		    double delta;
    Po> +		    double delta, scroll_unit;
 
    Po>  		    delta = x_get_scroll_valuator_delta (dpyinfo, xev->deviceid,
    Po>  							 i, *values, &val);
    Po> @@ -9943,6 +9943,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
    Po>  		    if (delta != DBL_MAX)
    Po>  		      {
    Po>  			f = mouse_or_wdesc_frame (dpyinfo, xev->event);
    Po> +			scroll_unit = pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0);
    Po>  			found_valuator = true;
 
    Po>  			if (signbit (delta) != signbit (val->emacs_value))
    Po> @@ -9975,7 +9976,15 @@ handle_one_xevent (struct x_display_info *dpyinfo,
    Po>  			inev.ie.modifiers
    Po>  			  |= x_x_to_emacs_modifiers (dpyinfo,
    xev-> mods.effective);
    Po> -			inev.ie.arg = Qnil;
    Po> +
    Po> +			if (val->horizontal)
    Po> +			  inev.ie.arg = list5 (Qnil, QCdelta_x,
    Po> +					       make_float (delta * scroll_unit),
    Po> +					       QCdelta_y, make_float (0));
    Po> +			else
    Po> +			  inev.ie.arg = list5 (Qnil, QCdelta_x, make_float (0),
    Po> +					       QCdelta_y,
    Po> +					       make_float (delta * scroll_unit));

So the :delta-y value is always 0 when :delta-x is non-zero and vice
versa? Why bother to return both then? (and why floats and not ints?).

Robert
-- 




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

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Wed, 17 Nov 2021 08:34:43 +0800
Robert Pluim <rpluim <at> gmail.com> writes:

> Is there really a need for this to be a plist with :delta-x and
> :delta-y in it? Just a cons of x and y would work.

Yes, what if other window systems decide to expose different values to
Lisp code?  Such as for example, the phase of the scroll.

> I donʼt think this is quite right. The 'X' is missing, and itʼs 'X'
> and 'Y' that give the number of pixels. And :delta-x and :delta-y
> (lowercase).

Thanks, I fixed that on my side.

> So the :delta-y value is always 0 when :delta-x is non-zero and vice
> versa? Why bother to return both then? (and why floats and not ints?).

Because other systems (such as GDK) have different methods of reporting
scroll deltas.  While it makes sense in the context of the XInput 2 code
to report them one at a time, it does not in the context of GDK, as it
reports both deltas to Emacs at the same time.

Which means the pure GTK port will report both delta-y and delta-x at
the same time.

Thanks.




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

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Wed, 17 Nov 2021 10:38:41 +0800
[Message part 1 (text/plain, inline)]
Po Lu <luangruo <at> yahoo.com> writes:

> Because other systems (such as GDK) have different methods of reporting
> scroll deltas.  While it makes sense in the context of the XInput 2 code
> to report them one at a time, it does not in the context of GDK, as it
> reports both deltas to Emacs at the same time.
>
> Which means the pure GTK port will report both delta-y and delta-x at
> the same time.
>
> Thanks.

And here's a new version of the patch with the fixes to documentation,
and an extra option to prevent motion events from being sent too
rapidly.

[0002-Expose-pixel-wise-wheel-events-to-Lisp.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Wed, 17 Nov 2021 13:34:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50;
 [PATCH] Pixel delta support for wheel events on X
Date: Wed, 17 Nov 2021 15:33:29 +0200
> Cc: 51891 <at> debbugs.gnu.org
> Date: Wed, 17 Nov 2021 10:38:41 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> --- a/doc/lispref/commands.texi
> +++ b/doc/lispref/commands.texi
> @@ -1985,7 +1985,11 @@ Misc Events
>  These kinds of event are generated by moving a mouse wheel.  The
>  @var{position} element is a mouse position list (@pxref{Click
>  Events}), specifying the position of the mouse cursor when the event
> -occurred.
> +occurred.  The event may have additional arguments after
> +@var{position}.  The third argument after @var{position}, if present,
> +is a property list of the form @w{@code{(:delta-x @var{x} :delta-y
> +@var{y})}}, where @var{x} and @var{y} are the number of pixels to
> +scroll by in each axis.

Did you consider the possibility of defining a new event?

And should mwheel.el be aware of this change somehow?

And finally, why introduce keyword-value pairs into a form that didn't
use them before?  Can we store just the values there?

> +			scroll_unit = pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0);

Ouch! can we avoid calling 'pow' here?  It's an expensive function.

> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
> +	       doc: /* Non-nil means to only send one wheel event for each scroll unit.
> +Otherwise, a wheel event will be sent every time the mouse wheel is
> +moved.

This is confusing: what does "scroll unit" mean in this context?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Thu, 18 Nov 2021 00:16:01 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Thu, 18 Nov 2021 08:15:27 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

> Did you consider the possibility of defining a new event?

Yes I did, but IMO it makes more sense to make this use the normal
`wheel-events'.

> And should mwheel.el be aware of this change somehow?

It doesn't have to.  A separate mwheel-scroll-*-function can be used to
implement pixel scrolling, once we get to that.

> And finally, why introduce keyword-value pairs into a form that didn't
> use them before?  Can we store just the values there?

Different window systems might have more/different information.  For
instace, I can imagine the GTK port wanting to include scroll phase and
inertia data into this propertly list.

>> +			scroll_unit = pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0);

> Ouch! can we avoid calling 'pow' here?  It's an expensive function.

That's what the other big users of XInput 2 do, including GTK+ and
Mozilla Firefox, and is unfortunately the only method of obtaining true
pixel scroll data from a scroll valuator.

>> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
>> +	       doc: /* Non-nil means to only send one wheel event for each scroll unit.
>> +Otherwise, a wheel event will be sent every time the mouse wheel is
>> +moved.

> This is confusing: what does "scroll unit" mean in this context?

An amount of scrolling that would previously generate a `mouse-4' or
`mouse-5' event.

But since I think most people don't know what such button events are,
it would not be sufficient to just put that into the doc string.

Any ideas?

Thanks!




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Thu, 18 Nov 2021 07:35:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Thu, 18 Nov 2021 09:33:51 +0200
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  51891 <at> debbugs.gnu.org
> Date: Thu, 18 Nov 2021 08:15:27 +0800
> 
> > And finally, why introduce keyword-value pairs into a form that didn't
> > use them before?  Can we store just the values there?
> 
> Different window systems might have more/different information.  For
> instace, I can imagine the GTK port wanting to include scroll phase and
> inertia data into this propertly list.

A Lisp object could have different types, one each for every use case
we want to support.  For example, we could use a single object there,
which in your case will be a list of 2 values, and in other cases will
have more members.  We do this kind of stuff all the time, including
in specifying POSITION in various events -- there are a gazillion of
different forms of POSITION already in Emacs.  I see no reason to
change the format when all we need to do is add one more form of
POSITION.

> >> +			scroll_unit = pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0);
> 
> > Ouch! can we avoid calling 'pow' here?  It's an expensive function.
> 
> That's what the other big users of XInput 2 do, including GTK+ and
> Mozilla Firefox, and is unfortunately the only method of obtaining true
> pixel scroll data from a scroll valuator.

Sorry, I don't understand: XInput2 knows about FRAME_PIXEL_HEIGHT of
our frames?

> >> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
> >> +	       doc: /* Non-nil means to only send one wheel event for each scroll unit.
> >> +Otherwise, a wheel event will be sent every time the mouse wheel is
> >> +moved.
> 
> > This is confusing: what does "scroll unit" mean in this context?
> 
> An amount of scrolling that would previously generate a `mouse-4' or
> `mouse-5' event.

That doesn't really answer my question.  Let me ask it differently:
how does "scroll unit" differ from "every time the wheel is moved"?

> But since I think most people don't know what such button events are,
> it would not be sufficient to just put that into the doc string.
> 
> Any ideas?

I might have ideas once I understand what you are trying to say ;-)




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

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Thu, 18 Nov 2021 17:17:25 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

> A Lisp object could have different types, one each for every use case
> we want to support.  For example, we could use a single object there,
> which in your case will be a list of 2 values, and in other cases will
> have more members.  We do this kind of stuff all the time, including
> in specifying POSITION in various events -- there are a gazillion of
> different forms of POSITION already in Emacs.  I see no reason to
> change the format when all we need to do is add one more form of
> POSITION.

That makes sense, I'll modify the change in a bit to report scroll
deltas as a pair of (DELTA-X . DELTA-Y) instead.

> Sorry, I don't understand: XInput2 knows about FRAME_PIXEL_HEIGHT of
> our frames?

Indeed it does.  It's the window server, after all.

>> An amount of scrolling that would previously generate a `mouse-4' or
>> `mouse-5' event.

> That doesn't really answer my question.  Let me ask it differently:
> how does "scroll unit" differ from "every time the wheel is moved"?

Basically, even tiny movements of the scroll wheel will cause XInput 2
to generate wheel events.  This makes the behavior stay like the
original by default, where you have to scroll 96 or so pixels before a
wheel event is actually sent.  (This is generally true, but certain mice
may behave differently.)

> I might have ideas once I understand what you are trying to say ;-)

Thanks, I hope what I just said clears things up a bit.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Thu, 18 Nov 2021 10:29:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Thu, 18 Nov 2021 18:27:44 +0800
[Message part 1 (text/plain, inline)]
Po Lu <luangruo <at> yahoo.com> writes:

> That makes sense, I'll modify the change in a bit to report scroll
> deltas as a pair of (DELTA-X . DELTA-Y) instead.

Here it is, and thanks in advance.

[0002-Expose-pixel-wise-wheel-events-to-Lisp.patch (text/x-patch, attachment)]

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Fri, 19 Nov 2021 15:05:40 +0200
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  51891 <at> debbugs.gnu.org
> Date: Thu, 18 Nov 2021 18:27:44 +0800
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > That makes sense, I'll modify the change in a bit to report scroll
> > deltas as a pair of (DELTA-X . DELTA-Y) instead.
> 
> Here it is, and thanks in advance.

Thanks, LGTM.  But I wonder whether we should have some more prominent
explanations in commands.texi about the significance of these wheel
events, and also some index entry to allow to find this quickly.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Fri, 19 Nov 2021 13:10:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Fri, 19 Nov 2021 15:09:44 +0200
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  51891 <at> debbugs.gnu.org
> Date: Thu, 18 Nov 2021 17:17:25 +0800
> 
> >> An amount of scrolling that would previously generate a `mouse-4' or
> >> `mouse-5' event.
> 
> > That doesn't really answer my question.  Let me ask it differently:
> > how does "scroll unit" differ from "every time the wheel is moved"?
> 
> Basically, even tiny movements of the scroll wheel will cause XInput 2
> to generate wheel events.  This makes the behavior stay like the
> original by default, where you have to scroll 96 or so pixels before a
> wheel event is actually sent.  (This is generally true, but certain mice
> may behave differently.)

Then the first sentence should probably be

  Non-nil means send a wheel event only for scrolling at least one screen line.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Fri, 19 Nov 2021 13:11:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Fri, 19 Nov 2021 21:10:14 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, LGTM.  But I wonder whether we should have some more prominent
> explanations in commands.texi about the significance of these wheel
> events, and also some index entry to allow to find this quickly.

I have no idea what further explanation to put in commands.texi.  As for
an idex entry, how about "pixel wheel events" or "pixel deltas in wheel
events"?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Fri, 19 Nov 2021 13:24:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Fri, 19 Nov 2021 15:23:52 +0200
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  51891 <at> debbugs.gnu.org
> Date: Fri, 19 Nov 2021 21:10:14 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks, LGTM.  But I wonder whether we should have some more prominent
> > explanations in commands.texi about the significance of these wheel
> > events, and also some index entry to allow to find this quickly.
> 
> I have no idea what further explanation to put in commands.texi.

Some text which makes it clear how these additional POSITION
parameters could be used by Lisp programs.

> As for an idex entry, how about "pixel wheel events" or "pixel
> deltas in wheel events"?

I think "pixel-resolution wheel events".




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Fri, 19 Nov 2021 13:26:01 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Fri, 19 Nov 2021 21:24:49 +0800
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

> Then the first sentence should probably be
>
>   Non-nil means send a wheel event only for scrolling at least one screen line.

Thanks.  Would it be OK for me to install this version of the change
that has the changes you proposed made?

[0001-Expose-pixel-wise-wheel-events-to-Lisp.patch (text/x-patch, attachment)]
[0001-Add-support-for-event-processing-via-XInput-2.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Fri, 19 Nov 2021 13:56:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Fri, 19 Nov 2021 15:55:17 +0200
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  51891 <at> debbugs.gnu.org
> Date: Fri, 19 Nov 2021 21:24:49 +0800
> 
> >   Non-nil means send a wheel event only for scrolling at least one screen line.
> 
> Thanks.  Would it be OK for me to install this version of the change
> that has the changes you proposed made?

Sure, why not?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Sat, 20 Nov 2021 00:31:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Sat, 20 Nov 2021 08:30:07 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

> Some text which makes it clear how these additional POSITION
> parameters could be used by Lisp programs.
> I think "pixel-resolution wheel events".

WDYT about the following passage?

  @cindex pixel-resolution wheel events
  You can use @var{x} and @var{y} to determine how much the mouse wheel
  has actually moved.  Scrolling the screen by these pixel deltas allows
  to present movement that appears to follow the user's grip on the
  mouse wheel.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51891; Package emacs. (Sat, 20 Nov 2021 07:07:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, 51891 <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Sat, 20 Nov 2021 09:06:28 +0200
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  51891 <at> debbugs.gnu.org
> Date: Sat, 20 Nov 2021 08:30:07 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Some text which makes it clear how these additional POSITION
> > parameters could be used by Lisp programs.
> > I think "pixel-resolution wheel events".
> 
> WDYT about the following passage?
> 
>   @cindex pixel-resolution wheel events
>   You can use @var{x} and @var{y} to determine how much the mouse wheel
>   has actually moved.

Here I would say "... has actually moved at pixel resolution."

>                       Scrolling the screen by these pixel deltas allows
>   to present movement that appears to follow the user's grip on the
>   mouse wheel.

That's just an example of using this feature, so:

  For example, the pixelwise deltas could be used to scroll the
  display at pixel resolution, exactly according to the user's turning
  the mouse wheel.

Thanks.




Reply sent to Po Lu <luangruo <at> yahoo.com>:
You have taken responsibility. (Sat, 20 Nov 2021 10:30:02 GMT) Full text and rfc822 format available.

Notification sent to Po Lu <luangruo <at> yahoo.com>:
bug acknowledged by developer. (Sat, 20 Nov 2021 10:30:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 51891-done <at> debbugs.gnu.org
Subject: Re: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel
 events on X
Date: Sat, 20 Nov 2021 18:28:54 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

> Sure, why not?
>
> Thanks.

Thanks, installed with the improvement to documentation you suggested in
the other message.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 18 Dec 2021 12:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 91 days ago.

Previous Next


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