[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master e37eb7f: Add support for pixel wheel deltas on NS

From: Po Lu
Subject: Re: master e37eb7f: Add support for pixel wheel deltas on NS
Date: Sat, 27 Nov 2021 18:54:42 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Nov 2021 15:14:13 +0800
>> >> On a reasonably sized frame that would be 1 to 2 pixels.
>> > Is this with a mouse wheel or with a touchpad?  I was asking about the
>> > mouse wheel.
>> This is with a mouse wheel that supports pixel values, i.e., a mouse
>> wheel that has no fixed "steps".  (A mouse wheel with fixed steps would
>> however report a value of 1.0: every XInput 2 program I tried will
>> scroll the close-to-100 pixels that implies on each turn of such a
>> wheel.)
> OK, thanks.
> Btw, I'm confused by the documentation of the enhanced mouse-wheel
> events.  The manual says
>   @item (wheel-up @var{position})
>   @itemx (wheel-down @var{position})
>   [...]
>                        The event may have additional arguments after
>   @var{position}.  The third argument after @var{position}, if present,
>   is a pair of the form @w{@code{(@var{x} . @var{y})}}, where @var{x}
>   and @var{y} are the number of pixels to scroll by in each axis.

> It mentions the 3rd argument (starting from 1, I presume, given the
> format of the event shown in @item).  But the code in pixel-scroll.el
> does:

It says "the third argument after @var{position}", which is the fifth
element (1-based) in the lispy event, as position is the second element
(again, one-based) of the event.

But I agree that the wording is confusing and can probably be improved
to just mention that the fifth element contains the pixel information.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]