From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly Date: Sun, 12 May 2019 17:36:50 +0300 Message-ID: <83pnonbuyl.fsf@gnu.org> References: <87y341q8cb.fsf@gmail.com> <83y33edr2a.fsf@gnu.org> <20190510212531.GA82150@breton.holly.idiocy.org> <83sgtleczm.fsf@gnu.org> <83a7ftdzq8.fsf@gnu.org> <20190511225021.GA82537@breton.holly.idiocy.org> <83zhnsb75h.fsf@gnu.org> <20190512110504.GA82901@breton.holly.idiocy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="67967"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35389@debbugs.gnu.org, rpluim@gmail.com, npostavs@gmail.com To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 12 16:38:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hPpcA-000HZQ-R9 for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 May 2019 16:38:11 +0200 Original-Received: from localhost ([127.0.0.1]:43855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPpc9-00072Y-Ob for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 May 2019 10:38:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPpc3-00072H-81 for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 10:38:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPpc2-0006Hd-25 for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 10:38:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57729) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPpc1-0006HZ-VM for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 10:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hPpc1-0002wI-OT for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 10:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 May 2019 14:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35389 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35389-submit@debbugs.gnu.org id=B35389.155767183711223 (code B ref 35389); Sun, 12 May 2019 14:38:01 +0000 Original-Received: (at 35389) by debbugs.gnu.org; 12 May 2019 14:37:17 +0000 Original-Received: from localhost ([127.0.0.1]:43040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPpbJ-0002ux-AB for submit@debbugs.gnu.org; Sun, 12 May 2019 10:37:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPpbH-0002ui-QQ for 35389@debbugs.gnu.org; Sun, 12 May 2019 10:37:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPpbC-0005y1-9W; Sun, 12 May 2019 10:37:10 -0400 Original-Received: from [176.228.60.248] (port=2252 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPpbB-0003qz-K4; Sun, 12 May 2019 10:37:10 -0400 In-reply-to: <20190512110504.GA82901@breton.holly.idiocy.org> (message from Alan Third on Sun, 12 May 2019 12:05:04 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159132 Archived-At: > Date: Sun, 12 May 2019 12:05:04 +0100 > From: Alan Third > 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.