bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel events on X

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  51891@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 ;-)