[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Touch events
Re: Touch events
Wed, 28 Jun 2017 22:06:40 +0100
On Wed, Jun 28, 2017 at 11:40:13AM +0200, Anders Lindgren wrote:
> > I’ve kept a separate ‘touch-scroll’ event as the mac port just embeds
> > that into the mouse-wheel events, but I feel there’s an argument to be
> > made that they should be handled differently.
> One thing that has annoyed me with the existing mouse-wheel events is that
> macOS sends implements a kind of inertia, resulting is a sequence of events
> a few seconds after I've stopped scrolling. Furthermore, if I have pressed,
> say, shift while scrolling and release the shift key while the extra events
> are arriving, the remaning events are treated as though they were
> unshifted, possibly executing a different Emacs command.
What makes scrolling with the trackpad on macOS so awkward is that
Cocoa is expecting the application to implement smooth scrolling, so
it sends events at a fairly high frequency. These events have pixel
based deltas, which are very often less than one line‐height.
Emacs sends one wheel up/down event per NS event, which results in far
more scrolling than expected.
The correct way to handle it is to add up the deltas until they exceed
one line‐height, and then scroll the relevant number of lines. I’ve
tried to implement something like that in lisp/touch.el in the
The other part of this is momentum. We should probably add a
customisation option to ignore events from the momentum phase. I
wouldn’t want to always ignore them, because people might expect Emacs
to scroll the same as other macOS apps. Especially if pixel scrolling
> It would be good to be able to get a single event for swipe commands (even
> though the inertia is useful for some commands).
> Ps. In the package https://github.com/Lindydancer/multicolumn I've
> implemented support for moving to next/prev/first/last window using
> horizontal swipes. To get around the extra events passed by the macOS, I'm
> using timers to silence scroll events for a while after a command has been
> handled, which clearly isn't a good technical solution.
Cocoa has a ‘swipe’ gesture separate from the normal scrolling
gesture. I don’t know what the difference is as I haven’t seen the
swipe gesture events showing up in my emacs yet, and I can’t find any
description of them online. It’s possible they’re a three‐finger
gesture, which are normally intercepted by the WM. I believe you can
turn the interception off.