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

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

[Robert Pluim]

>>>>> On Wed, 24 Nov 2021 22:09:23 -0500 (EST), oldosfan@savannah.gnu.org (Po Lu) said:

    Po> branch: master
    Po> commit e37eb7f5c67f7da2c78688eda8968562fe75b767
    Po> Author: Po Lu <luangruo@yahoo.com>
    Po> Commit: Po Lu <luangruo@yahoo.com>

    Po>     Add support for pixel wheel deltas on NS
    
    Po>     * src/xterm.c (x_coalesce_scroll_events): Update doc string.
    Po>     * src/nsterm.c (- mouseDown): Report pixel scroll deltas.

nsterm.m, not .c. I guess you didnʼt use C-x 4 a to write the log
message.

    Po> +
    Po> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
    Po> +	       doc: /* SKIP: real doc in xterm.c.  */);
    Po> +  x_coalesce_scroll_events = true;
    Po> +

We now have 3 definitions of x-coalesce-scroll-events. Is there not
somewhere more generic where you can put it? (and I suspect we can
drop the x- bit).

Robert
-- 

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

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

>     Po>     Add support for pixel wheel deltas on NS
>     
>     Po>     * src/xterm.c (x_coalesce_scroll_events): Update doc string.
>     Po>     * src/nsterm.c (- mouseDown): Report pixel scroll deltas.

> nsterm.m, not .c. I guess you didnʼt use C-x 4 a to write the log
> message.

That's right.  Good catch, sorry, but I couldn't get
add-change-log-entry to fill entries satisfactorily for use with Git.

>     Po> +
>     Po> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
>     Po> +	       doc: /* SKIP: real doc in xterm.c.  */);
>     Po> +  x_coalesce_scroll_events = true;
>     Po> +

> We now have 3 definitions of x-coalesce-scroll-events. Is there not
> somewhere more generic where you can put it? (and I suspect we can
> drop the x- bit).

Not until MS-Windows gains this support, I think.

Thanks.

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

[Robert Pluim]

>>>>> On Thu, 25 Nov 2021 18:34:14 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> Robert Pluim <rpluim@gmail.com> writes:
    Po> Add support for pixel wheel deltas on NS
    >> 
    Po> * src/xterm.c (x_coalesce_scroll_events): Update doc string.
    Po> * src/nsterm.c (- mouseDown): Report pixel scroll deltas.

    >> nsterm.m, not .c. I guess you didnʼt use C-x 4 a to write the log
    >> message.

    Po> That's right.  Good catch, sorry, but I couldn't get
    Po> add-change-log-entry to fill entries satisfactorily for use with Git.

add-change-log-entry doesnʼt need to fill the entry. You can refill in
the *vc-log* buffer when committing. Or recentish versions of magit
have a 'magit-generate-changelog' command. (please donʼt tell me
youʼre not using Emacs to commit changes :-) )

    Po> +
    Po> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
    Po> +	       doc: /* SKIP: real doc in xterm.c.  */);
    Po> +  x_coalesce_scroll_events = true;
    Po> +

    >> We now have 3 definitions of x-coalesce-scroll-events. Is there not
    >> somewhere more generic where you can put it? (and I suspect we can
    >> drop the x- bit).

    Po> Not until MS-Windows gains this support, I think.

Iʼm sure we have similar variables already, but none spring to mind
:-)

Robert
-- 

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 25 Nov 2021 11:26:17 +0100
> Cc: Po Lu <luangruo@yahoo.com>
> 
>     Po> +
>     Po> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
>     Po> +	       doc: /* SKIP: real doc in xterm.c.  */);
>     Po> +  x_coalesce_scroll_events = true;
>     Po> +
> 
> We now have 3 definitions of x-coalesce-scroll-events. Is there not
> somewhere more generic where you can put it? (and I suspect we can
> drop the x- bit).

keyboard.c, perhaps?

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 18:34:14 +0800
> 
> > We now have 3 definitions of x-coalesce-scroll-events. Is there not
> > somewhere more generic where you can put it? (and I suspect we can
> > drop the x- bit).
> 
> Not until MS-Windows gains this support, I think.

That's unrelated.  The doc string can always say that this has effect
only on this and that platform.

(And I really don't see what needs to be done on Windows, since it
seems already to report each wheel turn.  Perhaps I'm missing
something, in which case a test case to work with would be
appreciated.)

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

[Stefan Monnier]

>>     Po> +
>>     Po> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
>>     Po> +	       doc: /* SKIP: real doc in xterm.c.  */);
>>     Po> +  x_coalesce_scroll_events = true;
>>     Po> +
>> 
>> We now have 3 definitions of x-coalesce-scroll-events. Is there not
>> somewhere more generic where you can put it? (and I suspect we can
>> drop the x- bit).
>
> keyboard.c, perhaps?

Maybe a new `gui.c` where can put some of the code shared between the
various GUI-specific files?


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Robert Pluim <rpluim@gmail.com>,  luangruo@yahoo.com,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 13:46:21 -0500
> 
> >>     Po> +
> >>     Po> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
> >>     Po> +	       doc: /* SKIP: real doc in xterm.c.  */);
> >>     Po> +  x_coalesce_scroll_events = true;
> >>     Po> +
> >> 
> >> We now have 3 definitions of x-coalesce-scroll-events. Is there not
> >> somewhere more generic where you can put it? (and I suspect we can
> >> drop the x- bit).
> >
> > keyboard.c, perhaps?
> 
> Maybe a new `gui.c` where can put some of the code shared between the
> various GUI-specific files?

We already have that: xdisp.c.  But this is not GUI, this is about
input events.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That's unrelated.  The doc string can always say that this has effect
> only on this and that platform.

Hmm.  I understand now, thanks.

> (And I really don't see what needs to be done on Windows, since it
> seems already to report each wheel turn.  Perhaps I'm missing
> something, in which case a test case to work with would be
> appreciated.)

Someone needs to make it report the precision scroll information, and
optionally coalesce scroll events until at least a screen line has been
scrolled.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 08:39:21 +0800
> 
> > (And I really don't see what needs to be done on Windows, since it
> > seems already to report each wheel turn.  Perhaps I'm missing
> > something, in which case a test case to work with would be
> > appreciated.)
> 
> Someone needs to make it report the precision scroll information, and
> optionally coalesce scroll events until at least a screen line has been
> scrolled.

What is "precision scroll information", and how does it differ from
the information we receive from the mouse wheel on MS-Windows today?
AFAICT, we already get a window-system message for every movement of
the mouse wheel, so what else is needed?

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Someone needs to make it report the precision scroll information, and
>> optionally coalesce scroll events until at least a screen line has been
>> scrolled.

> What is "precision scroll information", and how does it differ from
> the information we receive from the mouse wheel on MS-Windows today?
> AFAICT, we already get a window-system message for every movement of
> the mouse wheel, so what else is needed?

Basically, we need to expose not only whether or not the mouse wheel has
been scrolled, but exactly how much it has been scrolled, each time a
wheel event is sent.

We expose it to Lisp as the amount of pixels the text should be scrolled
in each axis, as that is the most common format used by modern window
systems.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 15:00:40 +0800
> 
> > What is "precision scroll information", and how does it differ from
> > the information we receive from the mouse wheel on MS-Windows today?
> > AFAICT, we already get a window-system message for every movement of
> > the mouse wheel, so what else is needed?
> 
> Basically, we need to expose not only whether or not the mouse wheel has
> been scrolled, but exactly how much it has been scrolled, each time a
> wheel event is sent.
> 
> We expose it to Lisp as the amount of pixels the text should be scrolled
> in each axis, as that is the most common format used by modern window
> systems.

How to compute the amount of pixels for a given amount of wheel delta?
The wheel delta on MS-Windows is reported in abstract units, not
directly related to any pixels, AFAICT.  I don't see the logic of the
conversion to pixels documented anywhere in the X or NS code, and the
comments, such as they are, make no sense at all to someone who knows
nothing about X mouse-wheel handling.  In xterm.c, it seems like some
kind of query of the device "valuators" (whatever that is) is being
used?  And on NS, it seems like the delta is already reported in
pixels?

So I'm still in the dark here.  (We really need to document our
algorithms better, unless we assume only GUI experts will read and
maintain them.)

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> How to compute the amount of pixels for a given amount of wheel delta?

I don't know, but I will try to ask some people I know who know
something about this.

> The wheel delta on MS-Windows is reported in abstract units, not
> directly related to any pixels, AFAICT.  I don't see the logic of the
> conversion to pixels documented anywhere in the X or NS code, and the
> comments, such as they are, make no sense at all to someone who knows
> nothing about X mouse-wheel handling.  In xterm.c, it seems like some
> kind of query of the device "valuators" (whatever that is) is being
> used?

On X, the states of the mouse wheels in each axis are stored as absolute
values inside "valuators" attached to each mouse device.  To obtain the
delta of the scroll wheel from a motion event (which is used to report
that some valuator has changed), it is necessary to iterate over every
valuator that changed, and compare its previous value to the current
value of the valuator.

Each individual valuator also has an "interval", which is the amount you
must divide that delta by in order to obtain a delta in the terms of
scroll units.

This delta however is still intermediate, to make driver implementations
easier.  The XInput developers recommend the following algorithm to
convert from scroll unit deltas to pixel deltas:

  pixels_scrolled = pow (window_height, 2.0 / 3.0) * delta;

> And on NS, it seems like the delta is already reported in pixels?

Yes.  The PGTK port can do something similar if it gains support for
this, as GTK also reports it in pixels directly.

> So I'm still in the dark here.  (We really need to document our
> algorithms better, unless we assume only GUI experts will read and
> maintain them.)

Perhaps I should place my explanation of XInput 2 scroll handling in a
comment somewhere.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 17:37:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How to compute the amount of pixels for a given amount of wheel delta?
> 
> I don't know, but I will try to ask some people I know who know
> something about this.

Thanks.  But if this conversion is arbitrary (see below), I think I
know how to implement the MS-Windows version of "arbitrary".

> > The wheel delta on MS-Windows is reported in abstract units, not
> > directly related to any pixels, AFAICT.  I don't see the logic of the
> > conversion to pixels documented anywhere in the X or NS code, and the
> > comments, such as they are, make no sense at all to someone who knows
> > nothing about X mouse-wheel handling.  In xterm.c, it seems like some
> > kind of query of the device "valuators" (whatever that is) is being
> > used?
> 
> On X, the states of the mouse wheels in each axis are stored as absolute
> values inside "valuators" attached to each mouse device.  To obtain the
> delta of the scroll wheel from a motion event (which is used to report
> that some valuator has changed), it is necessary to iterate over every
> valuator that changed, and compare its previous value to the current
> value of the valuator.
> 
> Each individual valuator also has an "interval", which is the amount you
> must divide that delta by in order to obtain a delta in the terms of
> scroll units.
> 
> This delta however is still intermediate, to make driver implementations
> easier.  The XInput developers recommend the following algorithm to
> convert from scroll unit deltas to pixel deltas:
> 
>   pixels_scrolled = pow (window_height, 2.0 / 3.0) * delta;

All of this should be in comments in xterm.c.

Btw, the code calculates pixels_scrolled when it is not yet clear that
the value will be used, which is a waste of cycles, AFAICT.  How about
moving this closer to where the value is actually used?

In any case, are you saying that the conversion to pixels is somewhat
arbitrary?  And that users of X based systems have no control on this
conversion, i.e. users cannot determine the pixel equivalent of each
"delta"?

> > And on NS, it seems like the delta is already reported in pixels?
> 
> Yes.  The PGTK port can do something similar if it gains support for
> this, as GTK also reports it in pixels directly.

Same question here: do users have any system-wide control on the
conversion to pixels under these environments?

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks.  But if this conversion is arbitrary (see below), I think I
> know how to implement the MS-Windows version of "arbitrary".

Thanks!  I really appreciate it.

>> On X, the states of the mouse wheels in each axis are stored as absolute
>> values inside "valuators" attached to each mouse device.  To obtain the
>> delta of the scroll wheel from a motion event (which is used to report
>> that some valuator has changed), it is necessary to iterate over every
>> valuator that changed, and compare its previous value to the current
>> value of the valuator.
>> 
>> Each individual valuator also has an "interval", which is the amount you
>> must divide that delta by in order to obtain a delta in the terms of
>> scroll units.
>> 
>> This delta however is still intermediate, to make driver implementations
>> easier.  The XInput developers recommend the following algorithm to
>> convert from scroll unit deltas to pixel deltas:
>> 
>>   pixels_scrolled = pow (window_height, 2.0 / 3.0) * delta;
>
> All of this should be in comments in xterm.c.
>
> Btw, the code calculates pixels_scrolled when it is not yet clear that
> the value will be used, which is a waste of cycles, AFAICT.  How about
> moving this closer to where the value is actually used?

I'll do that, thanks.

> In any case, are you saying that the conversion to pixels is somewhat
> arbitrary?  And that users of X based systems have no control on this
> conversion, i.e. users cannot determine the pixel equivalent of each
> "delta"?

Yes, I'm using the method recommended by the XInput 2 developers, and on
X-based systems there's no option to control that arbitrary behaviour
that I know of.

It seems to be that every X-Windows program I checked (which includes
non-GTK programs such as Mozilla Firefox and Qt) also computes the pixel
information the same way.

>> Yes.  The PGTK port can do something similar if it gains support for
>> this, as GTK also reports it in pixels directly.

> Same question here: do users have any system-wide control on the
> conversion to pixels under these environments?

I don't know about NS, but there's no such option in GTK based systems.

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

[Eli Zaretskii]

Btw, I have a general question regarding this "pixel-resolution"
scrolling support:

With mwheel.el, Emacs users can configure the meaning of each scroll
event in terms of text lines, via the mouse-wheel-scroll-amount
variable.  But with this new mode, there's no such user control: the
conversion of the scroll amount reported by the wheel event to pixels
is either hard-coded in our code, or (on NS) determined by the OS.
Does it strike someone as "un-Emacsy"?

Also, if we detect that the mouse wheel is capable of reporting
fine-resolution scrolls, we use that unconditionally, and users have
no say about that.  So if a user sets x-coalesce-scroll-events to nil
manually, but doesn't enable this new mode, they suddenly get much
faster scrolling because mwheel.el disregards the pixel-wise deltas.
Right?  So maybe we should make x-coalesce-scroll-events and internal
variable, and say so in its doc string, because it should only be set
by this mode and its ilk, which do pay attention to the pixel deltas?

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, I have a general question regarding this "pixel-resolution"
> scrolling support:

> With mwheel.el, Emacs users can configure the meaning of each scroll
> event in terms of text lines, via the mouse-wheel-scroll-amount
> variable.  But with this new mode, there's no such user control: the
> conversion of the scroll amount reported by the wheel event to pixels
> is either hard-coded in our code, or (on NS) determined by the OS.
> Does it strike someone as "un-Emacsy"?

It seems OK to me, but we could perhaps have customizations for that.

The problem is that I don't see how such a customization could be
implemented on platforms such as NS, or in the future, the PGTK port.

> Also, if we detect that the mouse wheel is capable of reporting
> fine-resolution scrolls, we use that unconditionally, and users have
> no say about that.  So if a user sets x-coalesce-scroll-events to nil
> manually, but doesn't enable this new mode, they suddenly get much
> faster scrolling because mwheel.el disregards the pixel-wise deltas.
> Right?

Yes, that's correct.

> So maybe we should make x-coalesce-scroll-events and internal
> variable, and say so in its doc string, because it should only be set
> by this mode and its ilk, which do pay attention to the pixel deltas?

I could imagine some user customizations making use of it, but I have no
objection to making it an internal variable.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 20:05:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, I have a general question regarding this "pixel-resolution"
> > scrolling support:
> 
> > With mwheel.el, Emacs users can configure the meaning of each scroll
> > event in terms of text lines, via the mouse-wheel-scroll-amount
> > variable.  But with this new mode, there's no such user control: the
> > conversion of the scroll amount reported by the wheel event to pixels
> > is either hard-coded in our code, or (on NS) determined by the OS.
> > Does it strike someone as "un-Emacsy"?
> 
> It seems OK to me, but we could perhaps have customizations for that.
> 
> The problem is that I don't see how such a customization could be
> implemented on platforms such as NS, or in the future, the PGTK port.

It's simple: we could provide a variable to scale the pixels
calculated by the *term code.

> > So maybe we should make x-coalesce-scroll-events and internal
> > variable, and say so in its doc string, because it should only be set
> > by this mode and its ilk, which do pay attention to the pixel deltas?
> 
> I could imagine some user customizations making use of it, but I have no
> objection to making it an internal variable.

I'd be interested to hear opinions of Lars and others about this.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> It's simple: we could provide a variable to scale the pixels
> calculated by the *term code.

Alternatively, how about putting such an option in the code that makes
use of such events, something like `pixel-scroll-precision-scale'.

>> I could imagine some user customizations making use of it, but I have no
>> objection to making it an internal variable.

> I'd be interested to hear opinions of Lars and others about this.

Yes, I think that would be a good idea.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 19:44:59 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks.  But if this conversion is arbitrary (see below), I think I
> > know how to implement the MS-Windows version of "arbitrary".
> 
> Thanks!  I really appreciate it.

What pixel-delta values are typically reported on X for a single click
of the mouse wheel?

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

[Alan Third]

On Fri, Nov 26, 2021 at 08:37:08PM +0800, Po Lu wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It's simple: we could provide a variable to scale the pixels
> > calculated by the *term code.
> 
> Alternatively, how about putting such an option in the code that makes
> use of such events, something like `pixel-scroll-precision-scale'.

Why not move the delta to pixel conversion to lisp? On NS it defaults
to a 1:1 relationship, on X it defaults to the XInput2 devs
recommendation. The function could then be customised as desired by an
end user.

-- 
Alan Third

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

[Eli Zaretskii]

> Date: Fri, 26 Nov 2021 19:39:39 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, rpluim@gmail.com, emacs-devel@gnu.org
> 
> On Fri, Nov 26, 2021 at 08:37:08PM +0800, Po Lu wrote:
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > It's simple: we could provide a variable to scale the pixels
> > > calculated by the *term code.
> > 
> > Alternatively, how about putting such an option in the code that makes
> > use of such events, something like `pixel-scroll-precision-scale'.
> 
> Why not move the delta to pixel conversion to lisp?

Move it how?  Having each wheel event call into Lisp is not something
I'd like to do.

What kind of conversion do we need that is not a simple multiplication
by a user-customizable fixed value?  If this is all we need, the
conversion could be performed by the calling application.

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

[Alan Third]

On Fri, Nov 26, 2021 at 09:45:43PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 26 Nov 2021 19:39:39 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, rpluim@gmail.com, emacs-devel@gnu.org
> > 
> > On Fri, Nov 26, 2021 at 08:37:08PM +0800, Po Lu wrote:
> > > Eli Zaretskii <eliz@gnu.org> writes:
> > > 
> > > > It's simple: we could provide a variable to scale the pixels
> > > > calculated by the *term code.
> > > 
> > > Alternatively, how about putting such an option in the code that makes
> > > use of such events, something like `pixel-scroll-precision-scale'.
> > 
> > Why not move the delta to pixel conversion to lisp?
> 
> Move it how?  Having each wheel event call into Lisp is not something
> I'd like to do.

Hmm, I guess I'm mixing this up with the smooth scrolling work, which
is calling into lisp every time anyway.

Never mind.
-- 
Alan Third

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Thanks!  I really appreciate it.

> What pixel-delta values are typically reported on X for a single click
> of the mouse wheel?

A click (i.e. a movement where precise information is unavailable)?
Typically 1 scroll unit is reported, which would be:

    1.0 * pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0)

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 08:02:45 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Thanks!  I really appreciate it.
> 
> > What pixel-delta values are typically reported on X for a single click
> > of the mouse wheel?
> 
> A click (i.e. a movement where precise information is unavailable)?

Why are you saying "click" when we are talking about mouse wheel.  The
wheel is not clicked when the user wants to scroll, the wheel is
turned.

> Typically 1 scroll unit is reported, which would be:
> 
>     1.0 * pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0)

??? That's about 100 pixels on a reasonably-sized frame.  How can such
large values support "precision pixelwise scrolling"?

Are we talking about the same thing?  I was asking about the smallest
values of the deltas reported in the mouse wheel-up and wheel-down
events when the user turns the wheel the smallest amount possible.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> > What pixel-delta values are typically reported on X for a single
>> > click of the mouse wheel?
     ^^^^^

>> A click (i.e. a movement where precise information is unavailable)?

> Why are you saying "click" when we are talking about mouse wheel.  The
> wheel is not clicked when the user wants to scroll, the wheel is
> turned.

That is what you said, right?

>> Typically 1 scroll unit is reported, which would be:
>> 
>>     1.0 * pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0)

> ??? That's about 100 pixels on a reasonably-sized frame.  How can such
> large values support "precision pixelwise scrolling"?

> Are we talking about the same thing?  I was asking about the smallest
> values of the deltas reported in the mouse wheel-up and wheel-down
> events when the user turns the wheel the smallest amount possible.

Ahh, I understand what you're asking now.  The smallest value reported
is usually to 0.01 or so, after conversion into scroll units.

On a reasonably sized frame that would be 1 to 2 pixels.

I thought you were asking about the value reported before X sends a
legacy ButtonPress event for button 4/5/6/7.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 14:41:50 +0800
> 
> > Are we talking about the same thing?  I was asking about the smallest
> > values of the deltas reported in the mouse wheel-up and wheel-down
> > events when the user turns the wheel the smallest amount possible.
> 
> Ahh, I understand what you're asking now.  The smallest value reported
> is usually to 0.01 or so, after conversion into scroll units.
> 
> 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.

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

[Po Lu]

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 14:41:50 +0800
>> 
>> > Are we talking about the same thing?  I was asking about the smallest
>> > values of the deltas reported in the mouse wheel-up and wheel-down
>> > events when the user turns the wheel the smallest amount possible.
>> 
>> Ahh, I understand what you're asking now.  The smallest value reported
>> is usually to 0.01 or so, after conversion into scroll units.
>> 
>> 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.)

Thanks.

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

[Eli Zaretskii]

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

        (let ((delta (round (cdr (nth 4 event)))))

So it takes the 4th element (zero-based), which is a 2-element
discrepancy.  What is the real form of the enhanced wheel events, and
what are the 5 elements in them?  Or what am I missing here?

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

[Po Lu]

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.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 18:54:42 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 			 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.

So what are the two arguments between POSITION and (X . Y), the 3rd
and the 4th elements in the Lispy event?  They should be documented in
the general form of the event.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 27 Nov 2021 18:54:42 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 			 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.

> So what are the two arguments between POSITION and (X . Y), the 3rd
> and the 4th elements in the Lispy event?  They should be documented in
> the general form of the event.

I have no idea what they are, and as such couldn't document them.  (They
are not related to the pixel scrolling support.)

But I will try to find out.

Thanks.

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

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> I have no idea what they are, and as such couldn't document them.  (They
> are not related to the pixel scrolling support.)
>
> But I will try to find out.

I plan to change the mouse wheel section to the following text:

@cindex @code{wheel-up} event
@cindex @code{wheel-down} event
@item (wheel-up @var{position} @var{clicks} @var{lines} @var{pixel-delta})
@itemx (wheel-down @var{position})
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.

@var{clicks}, if present, is the number of times in quick succession
the wheel has been moved.  @xref{Repeat Events}.  @var{lines}, if
present, is the number of screen lines that should be scrolled.
@var{pixel-delta}, 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.

WDYT?  Also, it seems that `lines' is only generated by the NS port, so
it should perhaps be worthwhile to mention that as well?

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 19:13:44 +0800
> 
> @cindex @code{wheel-up} event
> @cindex @code{wheel-down} event
> @item (wheel-up @var{position} @var{clicks} @var{lines} @var{pixel-delta})
> @itemx (wheel-down @var{position})
> 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.
> 
> @var{clicks}, if present, is the number of times in quick succession
> the wheel has been moved.

By "if present", do you mean it can be absent, or do you mean it can
be nil?  If the latter, then "present" is not the right word.

Also, can this CLICKS member really be anything but 1 when the wheel
is used?

> @var{lines}, if present, is the number of screen lines that should
> be scrolled.  @var{pixel-delta}, 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.
> 
> WDYT?  Also, it seems that `lines' is only generated by the NS port, so
> it should perhaps be worthwhile to mention that as well?

Doesn't "if present" already handle that?  (Assuming you meant it can
be nil.)

Otherwise LGTM, thanks.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 27 Nov 2021 19:13:44 +0800
>> 
>> @cindex @code{wheel-up} event
>> @cindex @code{wheel-down} event
>> @item (wheel-up @var{position} @var{clicks} @var{lines} @var{pixel-delta})
>> @itemx (wheel-down @var{position})
>> 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.
>> 
>> @var{clicks}, if present, is the number of times in quick succession
>> the wheel has been moved.

> By "if present", do you mean it can be absent, or do you mean it can
> be nil?  If the latter, then "present" is not the right word.

It can be absent, not nil.  Thanks.

> Also, can this CLICKS member really be anything but 1 when the wheel
> is used?

Yes, when the wheel is turned quickly it can be 2 or 3.  It can probably
go higher, but I can't turn my mouse wheel that fast.

>> @var{lines}, if present, is the number of screen lines that should
>> be scrolled.  @var{pixel-delta}, 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.
>> 
>> WDYT?  Also, it seems that `lines' is only generated by the NS port, so
>> it should perhaps be worthwhile to mention that as well?

> Doesn't "if present" already handle that?

Yes, makes sense now, thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 19:34:19 +0800
> 
> >> @var{clicks}, if present, is the number of times in quick succession
> >> the wheel has been moved.
> 
> > By "if present", do you mean it can be absent, or do you mean it can
> > be nil?  If the latter, then "present" is not the right word.
> 
> It can be absent, not nil.  Thanks.

Hmm... now I'm confused.  Isn't this produced by this code in
keyboard.c:

	if (CONSP (event->arg))
	  return list5 (head, position, make_fixnum (double_click_count),
			XCAR (event->arg), Fcons (XCAR (XCDR (event->arg)),
						  XCAR (XCDR (XCDR (event->arg)))));

?  If so, this always produces a 5-element list, and CLICKS is always
included.  Right?

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 27 Nov 2021 19:34:19 +0800
>> 
>> >> @var{clicks}, if present, is the number of times in quick succession
>> >> the wheel has been moved.
>> 
>> > By "if present", do you mean it can be absent, or do you mean it can
>> > be nil?  If the latter, then "present" is not the right word.
>> 
>> It can be absent, not nil.  Thanks.
>
> Hmm... now I'm confused.  Isn't this produced by this code in
> keyboard.c:
>
> 	if (CONSP (event->arg))
> 	  return list5 (head, position, make_fixnum (double_click_count),
> 			XCAR (event->arg), Fcons (XCAR (XCDR (event->arg)),
> 						  XCAR (XCDR (XCDR (event->arg)))));
>
> ?  If so, this always produces a 5-element list, and CLICKS is always
> included.  Right?

Yes, but event->arg might not always be a cons.  On X, it is only a cons
in XInput 2 events that have precise scrolling information.  When
handling legacy events, it is nil.

AFAIU (and this may not be a very accurate understanding), if event->arg
is a cons, it means it might have line scroll information, and has pixel
scroll information.

Otherwise, if it is a number, it has only line information.

Otherwise, if the wheel event is double or triple, `double_click_count'
will be included.

And otherwise, only the event name and position will be included.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 19:44:15 +0800
> 
> > 	if (CONSP (event->arg))
> > 	  return list5 (head, position, make_fixnum (double_click_count),
> > 			XCAR (event->arg), Fcons (XCAR (XCDR (event->arg)),
> > 						  XCAR (XCDR (XCDR (event->arg)))));
> >
> > ?  If so, this always produces a 5-element list, and CLICKS is always
> > included.  Right?
> 
> Yes, but event->arg might not always be a cons.  On X, it is only a cons
> in XInput 2 events that have precise scrolling information.  When
> handling legacy events, it is nil.

I did mean what happens when the precise scrolling information is
there.

> AFAIU (and this may not be a very accurate understanding), if event->arg
> is a cons, it means it might have line scroll information, and has pixel
> scroll information.
> 
> Otherwise, if it is a number, it has only line information.
> 
> Otherwise, if the wheel event is double or triple, `double_click_count'
> will be included.
> 
> And otherwise, only the event name and position will be included.

So I think the manual should describe these possibilities, i.e. that
every member past POSITION can be present or absent, and if it's
present, the next one could be present or absent, etc.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I did mean what happens when the precise scrolling information is
> there.

Thanks, then in that case a 5-element list is always produced.

>> AFAIU (and this may not be a very accurate understanding), if event->arg
>> is a cons, it means it might have line scroll information, and has pixel
>> scroll information.
>> 
>> Otherwise, if it is a number, it has only line information.
>> 
>> Otherwise, if the wheel event is double or triple, `double_click_count'
>> will be included.
>> 
>> And otherwise, only the event name and position will be included.
>
> So I think the manual should describe these possibilities, i.e. that
> every member past POSITION can be present or absent, and if it's
> present, the next one could be present or absent, etc.

Does this look OK to you?  Thanks.

@item (wheel-up @var{position} @var{clicks} @var{lines} @var{pixel-delta})
@itemx (wheel-down @var{position} @var{clicks} @var{lines} @var{pixel-delta})
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.

@var{clicks}, if present, is the number of times in quick succession
the wheel has been moved.  @xref{Repeat Events}.  @var{lines}, if
present and not @code{nil}, is the number of screen lines that should
be scrolled.  @var{pixel-delta}, 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.

Each parameters after @var{position} may be absent.  Additionally,
@var{lines} may be @code{nil}.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 20:11:45 +0800
> 
> @item (wheel-up @var{position} @var{clicks} @var{lines} @var{pixel-delta})
> @itemx (wheel-down @var{position} @var{clicks} @var{lines} @var{pixel-delta})
> 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.
> 
> @var{clicks}, if present, is the number of times in quick succession
> the wheel has been moved.  @xref{Repeat Events}.  @var{lines}, if
> present and not @code{nil}, is the number of screen lines that should
> be scrolled.  @var{pixel-delta}, 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.
> 
> Each parameters after @var{position} may be absent.  Additionally,
> @var{lines} may be @code{nil}.

LGTM, but the last sentence is redundant, I think.  You already say
that above.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 27 Nov 2021 20:11:45 +0800
>> 
>> @item (wheel-up @var{position} @var{clicks} @var{lines} @var{pixel-delta})
>> @itemx (wheel-down @var{position} @var{clicks} @var{lines} @var{pixel-delta})
>> 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.
>> 
>> @var{clicks}, if present, is the number of times in quick succession
>> the wheel has been moved.  @xref{Repeat Events}.  @var{lines}, if
>> present and not @code{nil}, is the number of screen lines that should
>> be scrolled.  @var{pixel-delta}, 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.
>> 
>> Each parameters after @var{position} may be absent.  Additionally,
>> @var{lines} may be @code{nil}.
>
> LGTM, but the last sentence is redundant, I think.  You already say
> that above.

Okay, installed with the last sentence removed.

Thanks.

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

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> It's simple: we could provide a variable to scale the pixels
>> calculated by the *term code.
>
> Alternatively, how about putting such an option in the code that makes
> use of such events, something like `pixel-scroll-precision-scale'.

diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
index 888320cf1a..a14c211207 100644
--- a/lisp/pixel-scroll.el
+++ b/lisp/pixel-scroll.el
@@ -100,6 +100,11 @@ pixel-scroll-precision-mode-map
     map)
   "The key map used by `pixel-scroll-precision-mode'.")
 
+(defcustom pixel-scroll-precision-scale 1.0
+  "Value by which to multiply pixel deltas used in `pixel-scroll-precision-mode'."
+  :type 'float
+  :group 'mouse)
+
 (defun pixel-scroll-in-rush-p ()
   "Return non-nil if next scroll should be non-smooth.
 When scrolling request is delivered soon after the previous one,
@@ -476,7 +481,8 @@ pixel-scroll-precision
   (let ((window (mwheel-event-window event)))
     (if (and (nth 4 event)
              (zerop (window-hscroll window)))
-        (let ((delta (round (cdr (nth 4 event)))))
+        (let ((delta (round (* pixel-scroll-precision-scale
+                               (cdr (nth 4 event))))))
           (if (> (abs delta) (window-text-height window t))
               (mwheel-scroll event nil)
             (with-selected-window window
-- 
2.33.1

WDYT about this?  Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 28 Nov 2021 10:54:26 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> It's simple: we could provide a variable to scale the pixels
> >> calculated by the *term code.
> >
> > Alternatively, how about putting such an option in the code that makes
> > use of such events, something like `pixel-scroll-precision-scale'.
> 
> diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
> index 888320cf1a..a14c211207 100644
> --- a/lisp/pixel-scroll.el
> +++ b/lisp/pixel-scroll.el
> @@ -100,6 +100,11 @@ pixel-scroll-precision-mode-map
>      map)
>    "The key map used by `pixel-scroll-precision-mode'.")
>  
> +(defcustom pixel-scroll-precision-scale 1.0
> +  "Value by which to multiply pixel deltas used in `pixel-scroll-precision-mode'."
> +  :type 'float
> +  :group 'mouse)
> +

I think this factor should not be specific to pixel-scroll.el, it
should be applied by keyboard.c where it constructs the event, or
maybe by the *term.[cm] terminal-specific backends.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I think this factor should not be specific to pixel-scroll.el, it
> should be applied by keyboard.c where it constructs the event, or
> maybe by the *term.[cm] terminal-specific backends.

I think it makes more sense to put it in *term, as different terminals
use different methods to obtain the pixel deltas.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 28 Nov 2021 15:58:52 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think this factor should not be specific to pixel-scroll.el, it
> > should be applied by keyboard.c where it constructs the event, or
> > maybe by the *term.[cm] terminal-specific backends.
> 
> I think it makes more sense to put it in *term, as different terminals
> use different methods to obtain the pixel deltas.

Fine with me.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 28 Nov 2021 15:58:52 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I think this factor should not be specific to pixel-scroll.el, it
>> > should be applied by keyboard.c where it constructs the event, or
>> > maybe by the *term.[cm] terminal-specific backends.
>> 
>> I think it makes more sense to put it in *term, as different terminals
>> use different methods to obtain the pixel deltas.
>
> Fine with me.

I added such an option to the X port.  I will add a similar option to
the NS port once I get the virtual machine running macOS working again.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 15:39:44 +0800
> 
> >> I think it makes more sense to put it in *term, as different terminals
> >> use different methods to obtain the pixel deltas.
> >
> > Fine with me.
> 
> I added such an option to the X port.  I will add a similar option to
> the NS port once I get the virtual machine running macOS working again.

Thanks, but why do you allow only float values?  There's nothing wrong
with allowing integer values as well, is there?  You can use NUMBERP
and XFLOATINT instead of FLOATP and XFLOAT_DATA.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 29 Nov 2021 15:39:44 +0800
>> 
>> >> I think it makes more sense to put it in *term, as different terminals
>> >> use different methods to obtain the pixel deltas.
>> >
>> > Fine with me.
>> 
>> I added such an option to the X port.  I will add a similar option to
>> the NS port once I get the virtual machine running macOS working again.
>
> Thanks, but why do you allow only float values?  There's nothing wrong
> with allowing integer values as well, is there?  You can use NUMBERP
> and XFLOATINT instead of FLOATP and XFLOAT_DATA.

Thanks, I will fix that tomorrow.