bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Third
Subject: bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly
Date: Sun, 19 May 2019 13:32:01 +0100
User-agent: Mutt/1.11.3 (2019-02-01)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]