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

[Robert Pluim <rpluim@gmail.com>]

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