bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Robert Pluim]

I use the cus-edit+ package, which prompts you to save unsaved
customizations when you exit emacs. This triggers for me all the time,
because lisp/term/ns-win.el does 'setq' on mouse-wheel-scroll-amount
and mouse-wheel-progressive-speed, which I think is a no-no. The patch
below fixes it for me, but Iʼm utterly ignorant of customize, so
perhaps itʼs not the correct fix.

diff --git a/lisp/term/ns-win.el b/lisp/term/ns-win.el
index 6a668b213d..7899cbec3e 100644
--- a/lisp/term/ns-win.el
+++ b/lisp/term/ns-win.el
@@ -737,23 +737,15 @@ ns-version-string
 (defvar mouse-wheel-scroll-amount)
 (defvar mouse-wheel-progressive-speed)
 
-;; FIXME: This doesn't look right.  Is there a better way to do this
-;; that keeps customize happy?
 (when (featurep 'cocoa)
   (let ((appkit-version
          (progn (string-match "^appkit-\\([^\s-]*\\)" ns-version-string)
                 (string-to-number (match-string 1 ns-version-string)))))
     ;; Appkit 1138 ~= macOS 10.7.
     (when (>= appkit-version 1138)
-      (setq mouse-wheel-scroll-amount '(1 ((shift) . 5) ((control))))
-      (put 'mouse-wheel-scroll-amount 'customized-value
-           (list (custom-quote (symbol-value 'mouse-wheel-scroll-amount))))
-
-      (setq mouse-wheel-progressive-speed nil)
-      (put 'mouse-wheel-progressive-speed 'customized-value
-           (list (custom-quote
-                  (symbol-value 'mouse-wheel-progressive-speed)))))))
-
+      (custom-set-variables
+       (list 'mouse-wheel-scroll-amount ''(1 ((shift) . 5) ((control))) t)
+       (list 'mouse-wheel-progressive-speed nil t)))))
 
 ;;;; Color support.
 


In GNU Emacs 27.0.50 (build 6, x86_64-apple-darwin18.2.0, NS appkit-1671.20 Version 10.14.3 (Build 18D109))
 of 2019-04-19 built on rpluim-mac
Repository revision: e8124bfaaf8ba4a07beb4151fa7c5789a7de549c
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1671
System Description:  Mac OS X 10.14.3

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Noam Postavsky]

Robert Pluim <rpluim@gmail.com> writes:

> I use the cus-edit+ package, which prompts you to save unsaved
> customizations when you exit emacs. This triggers for me all the time,
> because lisp/term/ns-win.el does 'setq' on mouse-wheel-scroll-amount
> and mouse-wheel-progressive-speed, which I think is a no-no. The patch
> below fixes it for me, but Iʼm utterly ignorant of customize, so
> perhaps itʼs not the correct fix.

I think it should work to change customized-value to standard-value.

--- i/lisp/term/ns-win.el
+++ w/lisp/term/ns-win.el
@@ -746,11 +746,11 @@ (when (featurep 'cocoa)
     ;; Appkit 1138 ~= macOS 10.7.
     (when (>= appkit-version 1138)
       (setq mouse-wheel-scroll-amount '(1 ((shift) . 5) ((control))))
-      (put 'mouse-wheel-scroll-amount 'customized-value
+      (put 'mouse-wheel-scroll-amount 'standard-value
            (list (custom-quote (symbol-value 'mouse-wheel-scroll-amount))))
 
       (setq mouse-wheel-progressive-speed nil)
-      (put 'mouse-wheel-progressive-speed 'customized-value
+      (put 'mouse-wheel-progressive-speed 'standard-value
            (list (custom-quote
                   (symbol-value 'mouse-wheel-progressive-speed)))))))

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Robert Pluim]

>>>>> On Tue, 23 Apr 2019 07:17:24 -0400, Noam Postavsky <npostavs@gmail.com> said:

    Noam> Robert Pluim <rpluim@gmail.com> writes:
    >> I use the cus-edit+ package, which prompts you to save unsaved
    >> customizations when you exit emacs. This triggers for me all
    >> the time, because lisp/term/ns-win.el does 'setq' on
    >> mouse-wheel-scroll-amount and mouse-wheel-progressive-speed,
    >> which I think is a no-no. The patch below fixes it for me, but
    >> Iʼm utterly ignorant of customize, so perhaps itʼs not the
    >> correct fix.

    Noam> I think it should work to change customized-value to
    Noam> standard-value.

That works, thanks. Iʼll run with for a while then push to master.

Robert

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Robert Pluim]

>>>>> On Tue, 23 Apr 2019 13:38:59 +0200, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Tue, 23 Apr 2019 07:17:24 -0400, Noam Postavsky <npostavs@gmail.com> said:
    Noam> I think it should work to change customized-value to
    Noam> standard-value.

    Robert> That works, thanks. Iʼll run with for a while then push to
    Robert> master.

Having thought about this some more, does it make more sense to put
the value for macOS in the defcustoms for mouse-wheel-scroll-amount
and mouse-wheel-progressive-speed instead? (and discarding the test for
macOS < 10.7 at the same time) i.e.

diff --git a/lisp/mwheel.el b/lisp/mwheel.el
index 23f491db0f..4bed5b981d 100644
--- a/lisp/mwheel.el
+++ b/lisp/mwheel.el
@@ -85,7 +85,10 @@ mouse-wheel-inhibit-click-time
   :group 'mouse
   :type 'number)
 
-(defcustom mouse-wheel-scroll-amount '(5 ((shift) . 1) ((control) . nil))
+(defcustom mouse-wheel-scroll-amount
+  (if (featurep 'cocoa)
+      '(1 ((shift) . 5) ((control)))
+    '(5 ((shift) . 1) ((control) . nil)))
   "Amount to scroll windows by when spinning the mouse wheel.
 This is an alist mapping the modifier key to the amount to scroll when
 the wheel is moved with the modifier key depressed.
@@ -119,15 +122,20 @@ mouse-wheel-scroll-amount
                     (const :tag "Full screen" :value nil)
                     (integer :tag "Specific # of lines")
                     (float :tag "Fraction of window")))))
-  :set 'mouse-wheel-change-button)
+  :set 'mouse-wheel-change-button
+  :version "27.1")
 
-(defcustom mouse-wheel-progressive-speed t
+(defcustom mouse-wheel-progressive-speed
+  (if (featurep 'cocoa)
+      nil
+    t)
   "If non-nil, the faster the user moves the wheel, the faster the scrolling.
 Note that this has no effect when `mouse-wheel-scroll-amount' specifies
 a \"near full screen\" scroll or when the mouse wheel sends key instead
 of button events."
   :group 'mouse
-  :type 'boolean)
+  :type 'boolean
+  :version "27.1")
 
 (defcustom mouse-wheel-follow-mouse t
   "Whether the mouse wheel should scroll the window that the mouse is over.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 10 May 2019 17:29:46 +0200
> Cc: 35389@debbugs.gnu.org
> 
> Having thought about this some more, does it make more sense to put
> the value for macOS in the defcustoms for mouse-wheel-scroll-amount
> and mouse-wheel-progressive-speed instead? (and discarding the test for
> macOS < 10.7 at the same time) i.e.

Why does that system configuration need a different default to begin
with?  In general, having different defaults on different systems is
not a good idea.

Also, the original patch mentioned a specific version of appkit,
whereas this one is more general, AFAIU.  Wouldn't that cause trouble
or surprise elsewhere?

Thanks.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Fri, May 10, 2019 at 10:53:33PM +0300, Eli Zaretskii wrote:
> > From: Robert Pluim <rpluim@gmail.com>
> > Date: Fri, 10 May 2019 17:29:46 +0200
> > Cc: 35389@debbugs.gnu.org
> > 
> > Having thought about this some more, does it make more sense to put
> > the value for macOS in the defcustoms for mouse-wheel-scroll-amount
> > and mouse-wheel-progressive-speed instead? (and discarding the test for
> > macOS < 10.7 at the same time) i.e.
> 
> Why does that system configuration need a different default to begin
> with?  In general, having different defaults on different systems is
> not a good idea.

macOS 10.7+ handles wheel scrolling differently from how other systems
handle it. If we stick with the defaults then it becomes
uncontrollably fast, the current defaults make it feel similar to X,
Windows, etc.

IIRC, fixing it in C is probably possible, but not as straight forward
as just changing the defaults. There was discussion of it in Emacs
devel at the time and only one person objected, but later changed
their mind.

> Also, the original patch mentioned a specific version of appkit,
> whereas this one is more general, AFAIU.  Wouldn't that cause trouble
> or surprise elsewhere?

We still support macOS 10.6, which behaves similarly to X and Windows.
Changing the defaults for it would result in unexpected behaviour.
-- 
Alan Third

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> Date: Fri, 10 May 2019 22:25:31 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Robert Pluim <rpluim@gmail.com>, 35389@debbugs.gnu.org,
> 	npostavs@gmail.com
> 
> > Why does that system configuration need a different default to begin
> > with?  In general, having different defaults on different systems is
> > not a good idea.
> 
> macOS 10.7+ handles wheel scrolling differently from how other systems
> handle it. If we stick with the defaults then it becomes
> uncontrollably fast, the current defaults make it feel similar to X,
> Windows, etc.
> 
> IIRC, fixing it in C is probably possible, but not as straight forward
> as just changing the defaults. There was discussion of it in Emacs
> devel at the time and only one person objected, but later changed
> their mind.

Could there be some internal variable, either in Lisp or in C, which
we then would use in the default value, as some unit, instead of just
number of wheel turns and number of lines?  Then we could set that
internal variable to different values, but keep the customization the
same in those internally-defined units.  I think that would be
somewhat cleaner, if possible and reasonable, because we'd be able to
document the customization in these units in a platform-independent
way.

If that's impractical, then I guess we'll have to live with this
inconsistency, although I personally consider it a slippery slope.  At
the very least it should be documented, in NEWS if not in the manual.

> > Also, the original patch mentioned a specific version of appkit,
> > whereas this one is more general, AFAIU.  Wouldn't that cause trouble
> > or surprise elsewhere?
> 
> We still support macOS 10.6, which behaves similarly to X and Windows.
> Changing the defaults for it would result in unexpected behaviour.

Are you saying that testing the OS version and testing the appkit
version yield the same result in this case?  Or are you saying that
testing the appkit version is simply incorrect?  Because that was my
concern.

Thanks.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Robert Pluim]

>>>>> On Sat, 11 May 2019 09:12:13 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Fri, 10 May 2019 22:25:31 +0100 From: Alan Third
    >> <alan@idiocy.org> Cc: Robert Pluim <rpluim@gmail.com>,
    >> 35389@debbugs.gnu.org, npostavs@gmail.com
    >> 
    >> > Why does that system configuration need a different default
    >> to begin > with?  In general, having different defaults on
    >> different systems is > not a good idea.
    >> 
    >> macOS 10.7+ handles wheel scrolling differently from how other
    >> systems handle it. If we stick with the defaults then it
    >> becomes uncontrollably fast, the current defaults make it feel
    >> similar to X, Windows, etc.
    >> 
    >> IIRC, fixing it in C is probably possible, but not as straight
    >> forward as just changing the defaults. There was discussion of
    >> it in Emacs devel at the time and only one person objected, but
    >> later changed their mind.

Could you give a time range for when that was discussed?

    Eli> Could there be some internal variable, either in Lisp or in
    Eli> C, which we then would use in the default value, as some
    Eli> unit, instead of just number of wheel turns and number of
    Eli> lines?  Then we could set that internal variable to different
    Eli> values, but keep the customization the same in those
    Eli> internally-defined units.  I think that would be somewhat
    Eli> cleaner, if possible and reasonable, because we'd be able to
    Eli> document the customization in these units in a
    Eli> platform-independent way.

I canʼt think of a single variable you could use to transform

(5 ((shift) . 1) ((control) . nil)))

to

(1 ((shift) . 5) ((control)))

unless you want to start doing 'on macOS >= 10.7, divide by 5 if no
modifiers, multiply by five if shift', which could be done in lisp in
`mwheel-scroll', but it feels very hacky.

(as an aside ((control) . nil) is the same as ((control)), so we
should change one or the other)

    Eli> If that's impractical, then I guess we'll have to live with
    Eli> this inconsistency, although I personally consider it a
    Eli> slippery slope.  At the very least it should be documented,
    Eli> in NEWS if not in the manual.

Noam's original suggestion of patching ns-win.el might be best, then,
as it avoids any changes to the defcustom's.

    >> > Also, the original patch mentioned a specific version of
    >> appkit, > whereas this one is more general, AFAIU.  Wouldn't
    >> that cause trouble > or surprise elsewhere?
    >> 
    >> We still support macOS 10.6, which behaves similarly to X and
    >> Windows.  Changing the defaults for it would result in
    >> unexpected behaviour.

Thanks, I wasn't sure if 10.6 was still supported, so we'll have to
cater for that.

    Eli> Are you saying that testing the OS version and testing the
    Eli> appkit version yield the same result in this case?  Or are
    Eli> you saying that testing the appkit version is simply
    Eli> incorrect?  Because that was my concern.

I think testing the appkit version is correct (but Iʼm not the expert
here, Alan is).

Robert

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Alan Third <alan@idiocy.org>,  35389@debbugs.gnu.org,  npostavs@gmail.com
> Date: Sat, 11 May 2019 11:54:13 +0200
> 
>     Eli> Could there be some internal variable, either in Lisp or in
>     Eli> C, which we then would use in the default value, as some
>     Eli> unit, instead of just number of wheel turns and number of
>     Eli> lines?  Then we could set that internal variable to different
>     Eli> values, but keep the customization the same in those
>     Eli> internally-defined units.  I think that would be somewhat
>     Eli> cleaner, if possible and reasonable, because we'd be able to
>     Eli> document the customization in these units in a
>     Eli> platform-independent way.
> 
> I canʼt think of a single variable you could use to transform
> 
> (5 ((shift) . 1) ((control) . nil)))
> 
> to
> 
> (1 ((shift) . 5) ((control)))

What is the logic behind the value proposed for macOS 10.7, though?
It sounds like Shift will _increase_ the scrolling amount instead of
decreasing it in the default value?  What is the reason for such
reversal?

> (as an aside ((control) . nil) is the same as ((control)), so we
> should change one or the other)

Right.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Sat, May 11, 2019 at 01:58:39PM +0300, Eli Zaretskii wrote:
> > From: Robert Pluim <rpluim@gmail.com>
> > Cc: Alan Third <alan@idiocy.org>,  35389@debbugs.gnu.org,  npostavs@gmail.com
> > Date: Sat, 11 May 2019 11:54:13 +0200
> > 
> >     Eli> Could there be some internal variable, either in Lisp or in
> >     Eli> C, which we then would use in the default value, as some
> >     Eli> unit, instead of just number of wheel turns and number of
> >     Eli> lines?  Then we could set that internal variable to different
> >     Eli> values, but keep the customization the same in those
> >     Eli> internally-defined units.  I think that would be somewhat
> >     Eli> cleaner, if possible and reasonable, because we'd be able to
> >     Eli> document the customization in these units in a
> >     Eli> platform-independent way.
> > 
> > I canʼt think of a single variable you could use to transform
> > 
> > (5 ((shift) . 1) ((control) . nil)))
> > 
> > to
> > 
> > (1 ((shift) . 5) ((control)))
> 
> What is the logic behind the value proposed for macOS 10.7, though?
> It sounds like Shift will _increase_ the scrolling amount instead of
> decreasing it in the default value?  What is the reason for such
> reversal?

I can’t recall... I think it was just something somebody provided as
an option and nobody disagreed.

Some of the previous discussion is available here:

http://emacs.1067599.n8.nabble.com/Smoother-macOS-touchpad-scrolling-td435666.html

-- 
Alan Third

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> Date: Sat, 11 May 2019 23:50:21 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Robert Pluim <rpluim@gmail.com>, 35389@debbugs.gnu.org,
> 	npostavs@gmail.com
> 
> > > (5 ((shift) . 1) ((control) . nil)))
> > > 
> > > to
> > > 
> > > (1 ((shift) . 5) ((control)))
> > 
> > What is the logic behind the value proposed for macOS 10.7, though?
> > It sounds like Shift will _increase_ the scrolling amount instead of
> > decreasing it in the default value?  What is the reason for such
> > reversal?
> 
> I can’t recall... I think it was just something somebody provided as
> an option and nobody disagreed.
> 
> Some of the previous discussion is available here:
> 
> http://emacs.1067599.n8.nabble.com/Smoother-macOS-touchpad-scrolling-td435666.html

I don't see the above discrepancy discussed anywhere, nor any
justification for switching Shift from causing slower scrolling to
causing faster scrolling.  Did I miss something?

What I see is 2 kinds of arguments:

  . Acceleration applied by Emacs makes scrolling too fast because
    macOS itself accelerates by default

  . The default amount of scrolling -- 5 -- is too large for macOS
    (not sure why -- is that also due to macOS defaults?)

The first of these could be handled by turning acceleration off on
macOS 10.7 by default.  Maybe the same with the latter.  Although I
don't understand why the system's default scrolling should matter,
because AFAIK Emacs scrolls by its own commands, it doesn't use the
system for that.

Why Shift should _accelerate_ on macOS was never discussed, in any of
the linked discussions or the links inside them (stack-overflow etc.)

I understand now that this ship has sailed with Emacs 26, which I
regret, because I think it was a serious mistake to make at least part
of those changes.  Maybe we should try fixing that in future versions.

There's also the issue with trackball that differs from a real mouse
wheel.  I don't think I understand why it's an Emacs problem; do other
apps somehow distinguish between the trackball and the mouse and
produce a different behavior?  If so, why cannot Emacs distinguish
between them?

There was also a question in the 2017 discussion regarding how to know
we are near the top or bottom of the buffer.  is that still an issue?
Maybe I don't understand the problem, because the answer is trivial,
we have 2 macros that provide the limits of the buffer's accessible
portion, and another macro that provides the value of point.  If you
need the position of the window-start, that is also readily available.

Bottom line, I'd like to change Shift back to cause slow-down of the
scrolling, as on other platforms.  Maybe also change the default
itself back, and just make the acceleration off on macOS 10.7.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Sun, May 12, 2019 at 07:58:50AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 11 May 2019 23:50:21 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Robert Pluim <rpluim@gmail.com>, 35389@debbugs.gnu.org,
> > 	npostavs@gmail.com
> > 
> > > > (5 ((shift) . 1) ((control) . nil)))
> > > > 
> > > > to
> > > > 
> > > > (1 ((shift) . 5) ((control)))
> > > 
> > > What is the logic behind the value proposed for macOS 10.7, though?
> > > It sounds like Shift will _increase_ the scrolling amount instead of
> > > decreasing it in the default value?  What is the reason for such
> > > reversal?
> > 
> > I can’t recall... I think it was just something somebody provided as
> > an option and nobody disagreed.
> > 
> > Some of the previous discussion is available here:
> > 
> > http://emacs.1067599.n8.nabble.com/Smoother-macOS-touchpad-scrolling-td435666.html
> 
> I don't see the above discrepancy discussed anywhere, nor any
> justification for switching Shift from causing slower scrolling to
> causing faster scrolling.  Did I miss something?

No, I don’t think it was discussed at all. As I said I think it was
just thrown out there and nobody commented so it made it right
through. I don’t think it matters at all if we want to do something
different.

> What I see is 2 kinds of arguments:
> 
>   . Acceleration applied by Emacs makes scrolling too fast because
>     macOS itself accelerates by default
> 
>   . The default amount of scrolling -- 5 -- is too large for macOS
>     (not sure why -- is that also due to macOS defaults?)
>
> The first of these could be handled by turning acceleration off on
> macOS 10.7 by default.  Maybe the same with the latter.  Although I
> don't understand why the system's default scrolling should matter,
> because AFAIK Emacs scrolls by its own commands, it doesn't use the
> system for that.

I’ll try and explain how the scrolling works on macOS, that will
probably answer some of your questions.

The code in question is in nsterm.m in the method:

    - (void)mouseDown: (NSEvent *)theEvent

When a user scrolls with a scrollwheel on a mouse, one NSEvent is
created per ‘click’ of the wheel. The NSEvent provides a float that
describes how many lines the system believes that equates to, and as
you scroll more it increases the number of lines each click equates
to.

That is fine, we can ignore that and treat each click as one event in
Emacs.

When a user scrolls with a trackpad (dragging two fingers across the
surface) one or more NSEvents are generated, each of which contains a
number that equates to the number of pixels that the system thinks the
application should scroll. These numbers can be as little as one
pixel, or as high as 30 or 40 pixels or more.

Unfortunately we can’t just treat each of these NSEvents as a request
to scroll a single line as we can receive many small requests very
quickly. This is what Emacs used to do and it was basically useless.
The slightest two finger drag on the trackpad could result in Emacs
scrolling several pages.

What the current code does is add those pixel values up until they
reach a certain value, then send Emacs an event telling it to scroll.
Unfortunately those pixel values include a built‐in acceleration
factor, so the more the user drags their fingers across the trackpad,
the higher the pixel values will be, proportionally. We can’t disable
that, and as far as I can tell the user can’t even disable it for the
whole system.

To try and ignore the system’s acceleration I chose an arbitrary
number, and if the pixel values added up to more than that then
treated it as a single Emacs scroll event. Unfortunately a large two
finger drag on the trackpad can produce as few as one Emacs scroll
event when the user (or at least me) expects a greater amount of
scrolling.
 
> Why Shift should _accelerate_ on macOS was never discussed, in any of
> the linked discussions or the links inside them (stack-overflow etc.)

Indeed. I’d have no issue with changing that. My only concern is that
changing back to the defaults (i.e. scrolling 5 lines by default) may
be too fast due to the system acceleration.

> I understand now that this ship has sailed with Emacs 26, which I
> regret, because I think it was a serious mistake to make at least part
> of those changes.  Maybe we should try fixing that in future versions.
> 
> There's also the issue with trackball that differs from a real mouse
> wheel.  I don't think I understand why it's an Emacs problem; do other
> apps somehow distinguish between the trackball and the mouse and
> produce a different behavior?  If so, why cannot Emacs distinguish
> between them?

Emacs could easily differentiate between scrollwheel scrolls and
trackpad scrolls, but the infrastructure isn’t there. We could add a
new event type, for example. This may be useful for other ports when
we reach the point of being able to support gestures, if anyone ever
creates a native GTK port, say. But for now it would only be supported
on macOS, and I fear it might then become a political issue and have
to be disabled anyway.

If you have another idea, please let me know.

> There was also a question in the 2017 discussion regarding how to know
> we are near the top or bottom of the buffer.  is that still an issue?
> Maybe I don't understand the problem, because the answer is trivial,
> we have 2 macros that provide the limits of the buffer's accessible
> portion, and another macro that provides the value of point.  If you
> need the position of the window-start, that is also readily available.

Yes, it’s still an issue. macOS adds ‘momentum’ when the user finishes
scrolling with the trackpad. It’s easy to turn off, but when it’s on
it can continue to try scrolling at the top and bottom of the Emacs
buffer which results in a barrage of Emacs warnings complaining it’s
already at the top or bottom of the buffer.

Ideally this should return when it’s not able to scroll any more:

          /* FIXME: At the top or bottom of the buffer we should
           * ignore momentum-phase events.  */
          if (! ns_use_mwheel_momentum
              && [theEvent momentumPhase] != NSEventPhaseNone)
            return;

Emacs doesn’t scroll right to the bottom of the buffer, it always
displays two lines (perhaps more? I’m unsure if this is a setting
users can change). If the window is displaying the bottom two lines
and the user attempts to scroll down it displays a warning. I’d like
to be able to detect that Emacs can’t scroll any more, but that seems
a little more complex than checking that point is at the end of the
buffer.

This only affects ‘momentum’ phase scrolls. The simple solution is
ignore it or turn it off — we don’t need it — but it would be nice to
make it work properly.

I suppose if I could detect that the first or last line is being
displayed in the window then I could just ignore momentum. That’s
probably quite straight forward.

> Bottom line, I'd like to change Shift back to cause slow-down of the
> scrolling, as on other platforms.  Maybe also change the default
> itself back, and just make the acceleration off on macOS 10.7.


-- 
Alan Third

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> Date: Sun, 12 May 2019 12:05:04 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: rpluim@gmail.com, 35389@debbugs.gnu.org, npostavs@gmail.com
> 
> I’ll try and explain how the scrolling works on macOS, that will
> probably answer some of your questions.

Thanks, it does help.

> Unfortunately we can’t just treat each of these NSEvents as a request
> to scroll a single line as we can receive many small requests very
> quickly. This is what Emacs used to do and it was basically useless.
> The slightest two finger drag on the trackpad could result in Emacs
> scrolling several pages.
> 
> What the current code does is add those pixel values up until they
> reach a certain value, then send Emacs an event telling it to scroll.
> Unfortunately those pixel values include a built‐in acceleration
> factor, so the more the user drags their fingers across the trackpad,
> the higher the pixel values will be, proportionally. We can’t disable
> that, and as far as I can tell the user can’t even disable it for the
> whole system.

Is the algorithm used by the system to "accelerate" known?  If so,
could we "un-accelerate" those values, by scaling them back to the
original amount of dragging received from the user, as if acceleration
was disabled?  Then we could apply our own acceleration as on other
platforms.  Would that work?

If something like that does work, we could offer it, at least as an
option, for those who'd like Emacs to behave the same a on other
platforms.

> > Why Shift should _accelerate_ on macOS was never discussed, in any of
> > the linked discussions or the links inside them (stack-overflow etc.)
> 
> Indeed. I’d have no issue with changing that. My only concern is that
> changing back to the defaults (i.e. scrolling 5 lines by default) may
> be too fast due to the system acceleration.

Maybe we could scale the amount and/or undo the acceleration, to
countermand these effects?

> > There's also the issue with trackball that differs from a real mouse
> > wheel.  I don't think I understand why it's an Emacs problem; do other
> > apps somehow distinguish between the trackball and the mouse and
> > produce a different behavior?  If so, why cannot Emacs distinguish
> > between them?
> 
> Emacs could easily differentiate between scrollwheel scrolls and
> trackpad scrolls, but the infrastructure isn’t there. We could add a
> new event type, for example. This may be useful for other ports when
> we reach the point of being able to support gestures, if anyone ever
> creates a native GTK port, say. But for now it would only be supported
> on macOS, and I fear it might then become a political issue and have
> to be disabled anyway.

If Emacs handles this event internally, and just translates it to the
appropriate combination of wheel scroll events available on other
platforms, I see no political issues with that.  Later, if and when
such events are supported on other platforms, we could expose them on
macOS as well.

>           /* FIXME: At the top or bottom of the buffer we should
>            * ignore momentum-phase events.  */
>           if (! ns_use_mwheel_momentum
>               && [theEvent momentumPhase] != NSEventPhaseNone)
>             return;
> 
> Emacs doesn’t scroll right to the bottom of the buffer, it always
> displays two lines (perhaps more? I’m unsure if this is a setting
> users can change). If the window is displaying the bottom two lines
> and the user attempts to scroll down it displays a warning. I’d like
> to be able to detect that Emacs can’t scroll any more, but that seems
> a little more complex than checking that point is at the end of the
> buffer.
> 
> This only affects ‘momentum’ phase scrolls. The simple solution is
> ignore it or turn it off — we don’t need it — but it would be nice to
> make it work properly.
> 
> I suppose if I could detect that the first or last line is being
> displayed in the window then I could just ignore momentum. That’s
> probably quite straight forward.

I think vertical-motion is the primitive you are looking for, assuming
I understood the situation.  You can also call
Fline_beginning_position and Fline_end_position from C.

If these don't help, please tell why, maybe I don't have a clear idea
of the context in which you need to make these calls.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Sun, May 12, 2019 at 05:36:50PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 12 May 2019 12:05:04 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: rpluim@gmail.com, 35389@debbugs.gnu.org, npostavs@gmail.com
> > 
> > Unfortunately we can’t just treat each of these NSEvents as a request
> > to scroll a single line as we can receive many small requests very
> > quickly. This is what Emacs used to do and it was basically useless.
> > The slightest two finger drag on the trackpad could result in Emacs
> > scrolling several pages.
> > 
> > What the current code does is add those pixel values up until they
> > reach a certain value, then send Emacs an event telling it to scroll.
> > Unfortunately those pixel values include a built‐in acceleration
> > factor, so the more the user drags their fingers across the trackpad,
> > the higher the pixel values will be, proportionally. We can’t disable
> > that, and as far as I can tell the user can’t even disable it for the
> > whole system.
> 
> Is the algorithm used by the system to "accelerate" known?  If so,
> could we "un-accelerate" those values, by scaling them back to the
> original amount of dragging received from the user, as if acceleration
> was disabled?  Then we could apply our own acceleration as on other
> platforms.  Would that work?

I don’t think there’s a published algorithm. Generally Apple would
rather we all conform than do our own thing. After some thought I’ve
remembered that it’s possible to pick up the touch events at a lower
level, so it may be possible to do a comparison and try to reverse
engineer it. Or just bypass their scrolling completely. I’m not sure
how practical that would be though.

I hope your other questions were answered in the discussion with Tak,
so I won’t retread that ground here.
-- 
Alan Third

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Tak Kunihiro]

>> (1 ((shift) . 5) ((control)))
>
> No, I don’t think it was discussed at all. As I said I think it was
> just thrown out there and nobody commented so it made it right
> through. I don’t think it matters at all if we want to do something
> different.

I think I proposed to change the default to that value before.  What was
in my mind is to maintain controlling amount of scroll by shift key.

  1. Current default (5 ((shift) . 1) ((control))) with acceleration,
  the only concern is to scroll less.  My muscle leaned to control speed
  of scroll by pressing shift.
  
  2. Value (1 ((shift) . 1) ((control))) works good for me.  I never
  think about speeding down the scroll.  Occasionally I want to speed up
  scroll.

  3. Value (1 ((shift) . 5) ((control))) is good for typical scroll and
  occasional fast scroll with the muscle memory.

I'm not insisting to change the default, on this post.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> From: Tak Kunihiro <homeros.misasa@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  35389@debbugs.gnu.org,  rpluim@gmail.com,  npostavs@gmail.com
> Cc: tkk@misasa.okayama-u.ac.jp
> Date: Mon, 13 May 2019 08:29:28 +0900
> 
> >> (1 ((shift) . 5) ((control)))
> >
> > No, I don’t think it was discussed at all. As I said I think it was
> > just thrown out there and nobody commented so it made it right
> > through. I don’t think it matters at all if we want to do something
> > different.
> 
> I think I proposed to change the default to that value before.  What was
> in my mind is to maintain controlling amount of scroll by shift key.
> 
>   1. Current default (5 ((shift) . 1) ((control))) with acceleration,
>   the only concern is to scroll less.  My muscle leaned to control speed
>   of scroll by pressing shift.
>   
>   2. Value (1 ((shift) . 1) ((control))) works good for me.  I never
>   think about speeding down the scroll.  Occasionally I want to speed up
>   scroll.
> 
>   3. Value (1 ((shift) . 5) ((control))) is good for typical scroll and
>   occasional fast scroll with the muscle memory.

Item 3, the current default on macOS, makes Shift have the opposite
effect from what it produces on other platforms.  Which is in general
against our policy, AFAIU.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Tak Kunihiro]

>> >> (1 ((shift) . 5) ((control)))
>> >
>> > No, I don’t think it was discussed at all. As I said I think it was
>> > just thrown out there and nobody commented so it made it right
>> > through. I don’t think it matters at all if we want to do something
>> > different.
>> 
>> I think I proposed to change the default to that value before.  What was
>> in my mind is to maintain controlling amount of scroll by shift key.
>> 
>>   1. Current default (5 ((shift) . 1) ((control))) with acceleration,
>>   the only concern is to scroll less.  My muscle leaned to control speed
>>   of scroll by pressing shift.
>>   
>>   2. Value (1 ((shift) . 1) ((control))) works good for me.  I never
>>   think about speeding down the scroll.  Occasionally I want to speed up
>>   scroll.
>> 
>>   3. Value (1 ((shift) . 5) ((control))) is good for typical scroll and
>>   occasional fast scroll with the muscle memory.
>
> Item 3, the current default on macOS, makes Shift have the opposite
> effect from what it produces on other platforms.  Which is in general
> against our policy, AFAIU.

Value (1 ((shift) . 1) ((control))) isn't as useful as value (1 ((shift)
. 5) ((control))), is it?  If functionality of shift is described as
to change speed, the value can be fitted to the policy I suppose.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> From: Tak Kunihiro <homeros.misasa@gmail.com>
> Cc: Tak Kunihiro <homeros.misasa@gmail.com>,  alan@idiocy.org,  35389@debbugs.gnu.org,  rpluim@gmail.com,  npostavs@gmail.com
> Cc: tkk@misasa.okayama-u.ac.jp
> Date: Thu, 16 May 2019 18:00:25 +0900
> 
> >>   3. Value (1 ((shift) . 5) ((control))) is good for typical scroll and
> >>   occasional fast scroll with the muscle memory.
> >
> > Item 3, the current default on macOS, makes Shift have the opposite
> > effect from what it produces on other platforms.  Which is in general
> > against our policy, AFAIU.
> 
> Value (1 ((shift) . 1) ((control))) isn't as useful as value (1 ((shift)
> . 5) ((control))), is it?

The values can be floats, not just integers.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Tak Kunihiro]

>> >>   3. Value (1 ((shift) . 5) ((control))) is good for typical scroll and
>> >>   occasional fast scroll with the muscle memory.
>> >
>> > Item 3, the current default on macOS, makes Shift have the opposite
>> > effect from what it produces on other platforms.  Which is in general
>> > against our policy, AFAIU.
>> 
>> Value (1 ((shift) . 1) ((control))) isn't as useful as value (1 ((shift)
>> . 5) ((control))), is it?
>
> The values can be floats, not just integers.

True.  However, scrolling with float value is relative to number of
lines in a screen.  Value (1 ((shift) . 0.2) ((control))) is equal to
value (1 ((shift) . 10) ((control))).

To scroll less on shift, pixel-wise scroll is required, which is
possible on theory.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> From: Tak Kunihiro <homeros.misasa@gmail.com>
> Cc: Tak Kunihiro <homeros.misasa@gmail.com>,  alan@idiocy.org,  35389@debbugs.gnu.org,  rpluim@gmail.com,  npostavs@gmail.com
> Cc: tkk@misasa.okayama-u.ac.jp
> Date: Fri, 17 May 2019 08:24:48 +0900
> 
> >> Value (1 ((shift) . 1) ((control))) isn't as useful as value (1 ((shift)
> >> . 5) ((control))), is it?
> >
> > The values can be floats, not just integers.
> 
> True.  However, scrolling with float value is relative to number of
> lines in a screen.

Granted, I know that.  However, since Emacs knows the size of the
screen, it could compute the equivalent of lines in screen units.  And
even if not, the approximate size of today's windows is known in
advance, and what's important (to me) is to keep the slowing-down
effect of Shift, even if it slows down by a different ratio.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Tak Kunihiro]

>>>> Value (1 ((shift) . 1) ((control))) isn't as useful as value (1 ((shift)
>>>> . 5) ((control))), is it?
>>>
>>> The values can be floats, not just integers.
>> 
>> True.  However, scrolling with float value is relative to number of
>> lines in a screen.
>
> Granted, I know that.  However, since Emacs knows the size of the
> screen, it could compute the equivalent of lines in screen units.  And
> even if not, the approximate size of today's windows is known in
> advance, and what's important (to me) is to keep the slowing-down
> effect of Shift, even if it slows down by a different ratio.

To maintain relationship that is to scroll less on Shift, scroll with
Shift should be 3 pixel when scroll without Shift is 1 line (15 pixel).
I thought it is not possible to do even using float value.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> From: Tak Kunihiro <homeros.misasa@gmail.com>
> Cc: Tak Kunihiro <homeros.misasa@gmail.com>,  alan@idiocy.org,  35389@debbugs.gnu.org,  rpluim@gmail.com,  npostavs@gmail.com
> Cc: tkk@misasa.okayama-u.ac.jp
> Date: Sat, 18 May 2019 17:50:58 +0900
> 
> To maintain relationship that is to scroll less on Shift, scroll with
> Shift should be 3 pixel when scroll without Shift is 1 line (15 pixel).
> I thought it is not possible to do even using float value.

Doesn't the macOS implementation adds pixels until it gets enough for
scroll, before scrolling?  If so, why would it be impossible to equate
a mouse-wheel action to sub-line pixel number?

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Sat, May 18, 2019 at 12:16:06PM +0300, Eli Zaretskii wrote:
> > From: Tak Kunihiro <homeros.misasa@gmail.com>
> > Cc: Tak Kunihiro <homeros.misasa@gmail.com>,  alan@idiocy.org,  35389@debbugs.gnu.org,  rpluim@gmail.com,  npostavs@gmail.com
> > Cc: tkk@misasa.okayama-u.ac.jp
> > Date: Sat, 18 May 2019 17:50:58 +0900
> > 
> > To maintain relationship that is to scroll less on Shift, scroll with
> > Shift should be 3 pixel when scroll without Shift is 1 line (15 pixel).
> > I thought it is not possible to do even using float value.
> 
> Doesn't the macOS implementation adds pixels until it gets enough for
> scroll, before scrolling?  If so, why would it be impossible to equate
> a mouse-wheel action to sub-line pixel number?

IIRC it’s possible to set ns-mwheel-line-height to a value of 1 and
then the Emacs mwheel event (when generated from a touchpad scroll)
will have an argument that is exactly equivalent to the number of
pixels the system wants Emacs to scroll.


FWIW, a setting of

    (5 ((shift) . 1) ((control)))
    
is IMO perfectly usable. At least with progressive scroll off. The
only downsides are that it doesn’t match the way other apps work on my
desktop, and with a mousewheel (as opposed to a touchpad)
shift‐scrolling is captured by the OS and converted to horizontal
scrolling, so shift‐scroll does nothing anyway.

I still feel a default scroll amount of 1 feels much better, but it
may just be that I’m used to it.
-- 
Alan Third

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> Date: Sun, 19 May 2019 13:32:01 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Tak Kunihiro <homeros.misasa@gmail.com>, 35389@debbugs.gnu.org,
> 	rpluim@gmail.com, npostavs@gmail.com, tkk@misasa.okayama-u.ac.jp
> 
> FWIW, a setting of
> 
>     (5 ((shift) . 1) ((control)))
>     
> is IMO perfectly usable. At least with progressive scroll off. The
> only downsides are that it doesn’t match the way other apps work on my
> desktop, and with a mousewheel (as opposed to a touchpad)
> shift‐scrolling is captured by the OS and converted to horizontal
> scrolling, so shift‐scroll does nothing anyway.

Then I think we should make the above the default.

> I still feel a default scroll amount of 1 feels much better, but it
> may just be that I’m used to it.

People who want a behavior different from the default can always
customize, right?

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Tak Kunihiro]

>> FWIW, a setting of
>> 
>>     (5 ((shift) . 1) ((control)))
>>     
>> is IMO perfectly usable. At least with progressive scroll off. The
>> only downsides are that it doesn’t match the way other apps work on my
>> desktop, and with a mousewheel (as opposed to a touchpad)
>> shift‐scrolling is captured by the OS and converted to horizontal
>> scrolling, so shift‐scroll does nothing anyway.
>
> Then I think we should make the above the default.

I have no objection to it.

To be consistent among platform, should mouse-wheel-progressive-speed be
t?

>> I still feel a default scroll amount of 1 feels much better, but it
>> may just be that I’m used to it.
>
> People who want a behavior different from the default can always
> customize, right?

Yes.

I feel different default value is better as Alan inferred; however, I
think consistency among platform is important as well.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Eli Zaretskii]

> From: Tak Kunihiro <homeros.misasa@gmail.com>
> Cc: Alan Third <alan@idiocy.org>,  homeros.misasa@gmail.com,  35389@debbugs.gnu.org,  rpluim@gmail.com,  npostavs@gmail.com
> Cc: tkk@misasa.okayama-u.ac.jp
> Date: Thu, 23 May 2019 13:24:15 +0900
> 
> To be consistent among platform, should mouse-wheel-progressive-speed be
> t?

It'd be preferable, but I understand this makes Emacs on macOS
unusable with mouse scrolling, so I guess we will have to turn it off
by default on macOS.

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Tak Kunihiro]

>> To be consistent among platform, should mouse-wheel-progressive-speed be
>> t?
>
> It'd be preferable, but I understand this makes Emacs on macOS
> unusable with mouse scrolling, so I guess we will have to turn it off
> by default on macOS.

Following patch will make mouse-wheel-scroll-amount consistent among
platform.  Can you install it?

* Commit log

Author: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>

    Make mouse-wheel-scroll-amount consistent among platform
    
    * lisp/term/ns-win.el
    Do not put any values on mouse-wheel-scroll-amount on ns.

* Patch

diff --git a/lisp/term/ns-win.el b/lisp/term/ns-win.el
index 6a668b213d..15f3f76838 100644
--- a/lisp/term/ns-win.el
+++ b/lisp/term/ns-win.el
@@ -745,7 +745,6 @@ mouse-wheel-progressive-speed
                 (string-to-number (match-string 1 ns-version-string)))))
     ;; Appkit 1138 ~= macOS 10.7.
     (when (>= appkit-version 1138)
-      (setq mouse-wheel-scroll-amount '(1 ((shift) . 5) ((control))))
       (put 'mouse-wheel-scroll-amount 'customized-value
            (list (custom-quote (symbol-value 'mouse-wheel-scroll-amount))))

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Thu, Jun 06, 2019 at 11:21:38AM +0900, Tak Kunihiro wrote:
> >> To be consistent among platform, should mouse-wheel-progressive-speed be
> >> t?
> >
> > It'd be preferable, but I understand this makes Emacs on macOS
> > unusable with mouse scrolling, so I guess we will have to turn it off
> > by default on macOS.
> 
> Following patch will make mouse-wheel-scroll-amount consistent among
> platform.  Can you install it?

Done: 9f4c945b5cfb2e26a65ca10453591536c8fb0ff4.

Thanks.
-- 
Alan Third

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> On Thu, Jun 06, 2019 at 11:21:38AM +0900, Tak Kunihiro wrote:
>> >> To be consistent among platform, should mouse-wheel-progressive-speed be
>> >> t?
>> >
>> > It'd be preferable, but I understand this makes Emacs on macOS
>> > unusable with mouse scrolling, so I guess we will have to turn it off
>> > by default on macOS.
>> 
>> Following patch will make mouse-wheel-scroll-amount consistent among
>> platform.  Can you install it?
>
> Done: 9f4c945b5cfb2e26a65ca10453591536c8fb0ff4.

I've just skimmed this thread, but did this change make the originally
proposed patch unnecessary and this bug report can be closed? 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Robert Pluim]

>>>>> On Mon, 10 Aug 2020 13:32:50 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Alan Third <alan@idiocy.org> writes:
    >> On Thu, Jun 06, 2019 at 11:21:38AM +0900, Tak Kunihiro wrote:
    >>> >> To be consistent among platform, should mouse-wheel-progressive-speed be
    >>> >> t?
    >>> >
    >>> > It'd be preferable, but I understand this makes Emacs on macOS
    >>> > unusable with mouse scrolling, so I guess we will have to turn it off
    >>> > by default on macOS.
    >>> 
    >>> Following patch will make mouse-wheel-scroll-amount consistent among
    >>> platform.  Can you install it?
    >> 
    >> Done: 9f4c945b5cfb2e26a65ca10453591536c8fb0ff4.

    Lars> I've just skimmed this thread, but did this change make the originally
    Lars> proposed patch unnecessary and this bug report can be closed? 

Yes, I think so.

Robert

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>     Lars> I've just skimmed this thread, but did this change make the originally
>     Lars> proposed patch unnecessary and this bug report can be closed? 
>
> Yes, I think so.

OK; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Sat, May 11, 2019 at 11:54:13AM +0200, Robert Pluim wrote:
> >>>>> On Sat, 11 May 2019 09:12:13 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> Date: Fri, 10 May 2019 22:25:31 +0100 From: Alan Third
>     >> <alan@idiocy.org> Cc: Robert Pluim <rpluim@gmail.com>,
>     >> 35389@debbugs.gnu.org, npostavs@gmail.com
>     >> 
>     >> > Why does that system configuration need a different default
>     >> to begin > with?  In general, having different defaults on
>     >> different systems is > not a good idea.
>     >> 
>     >> macOS 10.7+ handles wheel scrolling differently from how other
>     >> systems handle it. If we stick with the defaults then it
>     >> becomes uncontrollably fast, the current defaults make it feel
>     >> similar to X, Windows, etc.
>     >> 
>     >> IIRC, fixing it in C is probably possible, but not as straight
>     >> forward as just changing the defaults. There was discussion of
>     >> it in Emacs devel at the time and only one person objected, but
>     >> later changed their mind.
> 
> Could you give a time range for when that was discussed?

September 2017, apparently. I’ve provided a link in my reply to Eli.

>     Eli> Are you saying that testing the OS version and testing the
>     Eli> appkit version yield the same result in this case?  Or are
>     Eli> you saying that testing the appkit version is simply
>     Eli> incorrect?  Because that was my concern.
> 
> I think testing the appkit version is correct (but Iʼm not the expert
> here, Alan is).

It’s really six of one and half a dozen of the other. As far as I’m
aware each Appkit version always matches to a macOS version, although
the documentation says that’s not guaranteed. As I recall we went with
Appkit version because that was more readily available.
-- 
Alan Third

bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Sat, May 11, 2019 at 09:12:13AM +0300, Eli Zaretskii wrote:
> 
> Could there be some internal variable, either in Lisp or in C, which
> we then would use in the default value, as some unit, instead of just
> number of wheel turns and number of lines?  Then we could set that
> internal variable to different values, but keep the customization the
> same in those internally-defined units.  I think that would be
> somewhat cleaner, if possible and reasonable, because we'd be able to
> document the customization in these units in a platform-independent
> way.

The big issue is that both macOS and Emacs accelerate the scroll rate,
and that results in uncontrollable scroll rates.

Looking through previous discussions (link provided in another email
in this thread) it appears there’s an unfortunate trade‐off to be made
in how we handle scrolling acceleration varying between mousewheels
and trackpads on macOS.

The built‐in macOS acceleration feels natural on both, the Emacs
acceleration feels very slow on trackpads.

> If that's impractical, then I guess we'll have to live with this
> inconsistency, although I personally consider it a slippery slope.  At
> the very least it should be documented, in NEWS if not in the manual.

It was documented in NEWS for Emacs 26.

I don’t recall if it was added to the manual. A thorough review of the
macOS section of the manual is on my todo list for before Emacs 27 is
released.
-- 
Alan Third