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

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
Robert Pluim <[hidden email]> 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)))))))



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> said:

    Noam> Robert Pluim <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> said:

>>>>> On Tue, 23 Apr 2019 07:17:24 -0400, Noam Postavsky <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Robert Pluim <[hidden email]>
> Date: Fri, 10 May 2019 17:29:46 +0200
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> > Date: Fri, 10 May 2019 17:29:46 +0200
> > Cc: [hidden email]
> >
> > 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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> Cc: Robert Pluim <[hidden email]>, [hidden email],
> [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> said:

    >> Date: Fri, 10 May 2019 22:25:31 +0100 From: Alan Third
    >> <[hidden email]> Cc: Robert Pluim <[hidden email]>,
    >> [hidden email], [hidden email]
    >>
    >> > 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Robert Pluim <[hidden email]>
> Cc: Alan Third <[hidden email]>,  [hidden email],  [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> > Cc: Alan Third <[hidden email]>,  [hidden email],  [hidden email]
> > 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



Reply | Threaded
Open this post in threaded view
|

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

Alan Third
In reply to this post by Robert Pluim
On Sat, May 11, 2019 at 11:54:13AM +0200, Robert Pluim wrote:

> >>>>> On Sat, 11 May 2019 09:12:13 +0300, Eli Zaretskii <[hidden email]> said:
>
>     >> Date: Fri, 10 May 2019 22:25:31 +0100 From: Alan Third
>     >> <[hidden email]> Cc: Robert Pluim <[hidden email]>,
>     >> [hidden email], [hidden email]
>     >>
>     >> > 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



Reply | Threaded
Open this post in threaded view
|

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

Alan Third
In reply to this post by Eli Zaretskii
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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Alan Third
> Date: Sat, 11 May 2019 23:50:21 +0100
> From: Alan Third <[hidden email]>
> Cc: Robert Pluim <[hidden email]>, [hidden email],
> [hidden email]
>
> > > (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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> > Cc: Robert Pluim <[hidden email]>, [hidden email],
> > [hidden email]
> >
> > > > (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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Tak Kunihiro-3
In reply to this post by Alan Third
>> (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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Tak Kunihiro <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>,  [hidden email],  [hidden email],  [hidden email]
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Tak Kunihiro-3
>> >> (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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Tak Kunihiro <[hidden email]>
> Cc: Tak Kunihiro <[hidden email]>,  [hidden email],  [hidden email],  [hidden email],  [hidden email]
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Tak Kunihiro-3
>> >>   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.



12