Pixel scrolling support

Pixel scrolling support

[Po Lu]

[-- Attachment #1: Type: text/plain, Size: 46 bytes --]


I would like to install the following file:


[-- Attachment #2: better-pixel-scroll.el --]
[-- Type: text/plain, Size: 4470 bytes --]

;;; better-pixel-scroll.el --- Pixel scrolling support  -*- lexical-binding:t -*-

;; Copyright (C) 2021 Free Software Foundation, Inc.

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;; This enables the use of smooth scroll events provided by XInput 2
;; or NS to scroll the display according to the user's precise turning
;; of the mouse wheel.

;;; Code:

(require 'mwheel)

(defvar x-coalesce-scroll-events)

(defvar better-pixel-scroll-mode-map (make-sparse-keymap)
  "The key map used by `better-pixel-scroll-mode'.")

(define-key better-pixel-scroll-mode-map [wheel-down] #'better-pixel-scroll)
(define-key better-pixel-scroll-mode-map [wheel-up] #'better-pixel-scroll)

(defun better-pixel-scroll-scroll-down (delta)
  "Scroll the current window down by DELTA pixels.
Note that this function doesn't work if DELTA is larger than
the height of the current window."
  (when-let* ((posn (posn-at-point))
	      (current-y (cdr (posn-x-y posn)))
	      (min-y (+ (window-tab-line-height)
		        (window-header-line-height))))
    (if (> delta 0)
	(while (< (- current-y min-y) delta)
	  (vertical-motion 1)
          (setq current-y (+ current-y
                             (line-pixel-height)))
	  (when (eobp)
	    (error "End of buffer")))))
  (let* ((desired-pos (posn-at-x-y 0 (+ delta
					(window-tab-line-height)
					(window-header-line-height))))
	 (desired-start (posn-point desired-pos))
	 (desired-vscroll (cdr (posn-object-x-y desired-pos))))
    (unless (eq (window-start) desired-start)
      (set-window-start nil desired-start t))
    (set-window-vscroll nil desired-vscroll t)))

(defun better-pixel-scroll-scroll-up (delta)
  "Scroll the current window up by DELTA pixels."
  (let* ((max-y (- (window-text-height nil t)
		   (window-tab-line-height)
		   (window-header-line-height)))
	 (posn (posn-at-point))
	 (current-y (+ (cdr (posn-x-y posn))
		       (cdr (posn-object-width-height posn)))))
    (while (< (- max-y current-y) delta)
      (setq current-y (- current-y (line-pixel-height)))
      (when (zerop (vertical-motion -1))
	(set-window-vscroll nil 0)
	(signal 'beginning-of-buffer nil))))
  (while (> delta 0)
    (set-window-start nil (save-excursion
                            (goto-char (window-start))
                            (when (zerop (vertical-motion -1))
			      (set-window-vscroll nil 0)
			      (signal 'beginning-of-buffer nil))
                            (setq delta (- delta (line-pixel-height)))
                            (point))
		      t))
  (when (< delta 0)
    (better-pixel-scroll-scroll-down (- delta))))

(defun better-pixel-scroll (event &optional arg)
  "Scroll the display according to EVENT.
Take into account any pixel deltas in EVENT to scroll the display
according to the user's turning the mouse wheel.  If EVENT does
not have precise scrolling deltas, call `mwheel-scroll' instead.
ARG is passed to `mwheel-scroll', should that be called."
  (interactive (list last-input-event current-prefix-arg))
  (if (nth 4 event)
      (let ((delta (round (cdr (nth 4 event))))
            (window (mwheel-event-window event)))
        (if (> (abs delta) (window-text-height window t))
            (mwheel-scroll event arg)
          (with-selected-window window
              (if (< delta 0)
	          (better-pixel-scroll-scroll-down (- delta))
                (better-pixel-scroll-scroll-up delta)))))
    (mwheel-scroll event arg)))

;;;###autoload
(define-minor-mode better-pixel-scroll-mode
  "Toggle pixel scrolling.
When enabled, this minor mode allows to scroll the display
precisely, according to the turning of the mouse wheel."
  :global t
  :group 'mouse
  :keymap better-pixel-scroll-mode-map
  (setq x-coalesce-scroll-events
        (not better-pixel-scroll-mode)))

(provide 'better-pixel-scroll)

;;; better-pixel-scroll.el ends herea

[-- Attachment #3: Type: text/plain, Size: 203 bytes --]


on master, with an appropriate entry in NEWS.  It defines a global minor
mode that lets the user scroll the display according to the pixel
information reported by his mouse wheel.

Is that OK?  Thanks.

Re: Pixel scrolling support

[Stefan Monnier]

Po Lu [2021-11-26 08:35:12] wrote:
> I would like to install the following file:

Looks OK to me, tho I wonder why you'd want to use a separate file
rather than add this directly in `mwheel.el`.

Also, see a few more comments below.


        Stefan


> (defvar better-pixel-scroll-mode-map (make-sparse-keymap)
>   "The key map used by `better-pixel-scroll-mode'.")
>
> (define-key better-pixel-scroll-mode-map [wheel-down] #'better-pixel-scroll)
> (define-key better-pixel-scroll-mode-map [wheel-up] #'better-pixel-scroll)

Please combine this into

(defvar better-pixel-scroll-mode-map
  (let ((map (make-sparse-keymap)))
    (define-key map [wheel-down] #'better-pixel-scroll)
    (define-key map [wheel-up] #'better-pixel-scroll)
    map)
  "The key map used by `better-pixel-scroll-mode'.")

Or better yet use `defvar-keymap`.

> ;;;###autoload
> (define-minor-mode better-pixel-scroll-mode
>   "Toggle pixel scrolling.
> When enabled, this minor mode allows to scroll the display
> precisely, according to the turning of the mouse wheel."
>   :global t
>   :group 'mouse
>   :keymap better-pixel-scroll-mode-map
>   (setq x-coalesce-scroll-events
>         (not better-pixel-scroll-mode)))

The `:keymap` arg is redundant.

Re: Pixel scrolling support

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Looks OK to me, tho I wonder why you'd want to use a separate file
> rather than add this directly in `mwheel.el`.

I think it's out of scope for mwheel.el.

> Also, see a few more comments below.

Thanks, fixed and pushed.

There are still some problems with scrolling through tall images.  I
can't figure them out, but someone should take a look.

Re: Pixel scrolling support

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> There are still some problems with scrolling through tall images.  I
> can't figure them out, but someone should take a look.

Actually, I would really appreciate someone taking a look at this
problem.

Enable `better-pixel-scroll-mode', load gnu.org in eww, and try to
scroll down with a touchpad.  The problem should be fairly obvious at
that point.

Thanks.

Re: Pixel scrolling support

[Aaron Madlon-Kay]

Thank you for this. I've been enjoying pixel scrolling in the Mac
port, so it's nice to see it in NS as well.

One thing I noticed is that if I scroll in a way that has some
momentum (my MacBook's trackpad) and the momentum would try to scroll
the content beyond the boundary of the window (i.e. beyond the very
top or very bottom), then there is a cacophony of beeps as it tries to
overscroll many times in quick succession.

An easy way to see this is simply to M-x beginning-of-buffer in pretty
much any buffer and then attempt to scroll up.

-Aaron

On Fri, Nov 26, 2021 at 9:36 AM Po Lu <luangruo@yahoo.com> wrote:
>
>
> I would like to install the following file:
>
>
> on master, with an appropriate entry in NEWS.  It defines a global minor
> mode that lets the user scroll the display according to the pixel
> information reported by his mouse wheel.
>
> Is that OK?  Thanks.

Re: Pixel scrolling support

[Po Lu]

Aaron Madlon-Kay <aaron+emacs@madlon-kay.com> writes:

> Thank you for this. I've been enjoying pixel scrolling in the Mac
> port, so it's nice to see it in NS as well.

> One thing I noticed is that if I scroll in a way that has some
> momentum (my MacBook's trackpad) and the momentum would try to scroll
> the content beyond the boundary of the window (i.e. beyond the very
> top or very bottom), then there is a cacophony of beeps as it tries to
> overscroll many times in quick succession.

> An easy way to see this is simply to M-x beginning-of-buffer in pretty
> much any buffer and then attempt to scroll up.

Hmm...  I didn't develop the NS version of pixel scrolling very much,
and most of the testing was done with the XInput 2 version, but could
you please check if setting `ns-use-mwheel-momentum' rectifies this
problem?

Thanks.

Re: Pixel scrolling support

[Aaron Madlon-Kay]

On Fri, Nov 26, 2021 at 3:00 PM Po Lu <luangruo@yahoo.com> wrote:
>
> Hmm...  I didn't develop the NS version of pixel scrolling very much,
> and most of the testing was done with the XInput 2 version, but could
> you please check if setting `ns-use-mwheel-momentum' rectifies this
> problem?

Setting `ns-use-mwheel-momentum` to nil reduces the cacophony a little
bit, but does not eliminate it. `ns-use-mwheel-acceleration` doesn't
seem to help either.

I would also point out that using wheel momentum is desirable in
general, so as a workaround it's a bit unsatisfying.

-Aaron

Re: Pixel scrolling support

[Jim Porter]

On 11/25/2021 4:35 PM, Po Lu wrote:
> It defines a global minor mode that lets the user scroll the display
> according to the pixel information reported by his mouse wheel.

This looks quite interesting. Is the plan to incorporate this into 
pixel-scroll.el once you're confident everything works correctly? (I see 
in another part of the thread that you're still working through some 
issues with scrolling across tall images.)

I think it would be nice to have a single `pixel-scroll-mode' that just 
uses the best method available to scroll pixel-wise. That is, use this 
better implementation on XInput2 or NS, but use the old 
`pixel-scroll-mode' implementation elsewhere.

- Jim

Re: Pixel scrolling support

[Po Lu]

Jim Porter <jporterbugs@gmail.com> writes:

> This looks quite interesting. Is the plan to incorporate this into
> pixel-scroll.el once you're confident everything works correctly? (I
> see in another part of the thread that you're still working through
> some issues with scrolling across tall images.)

I can't figure out the image scrolling part, so someone else will
probably have to take a look at it.  (Thanks in advance.)

> I think it would be nice to have a single `pixel-scroll-mode' that
> just uses the best method available to scroll pixel-wise. That is, use
> this better implementation on XInput2 or NS, but use the old
> `pixel-scroll-mode' implementation elsewhere.

I don't know how that would work, but it seems like a good idea.

Thanks.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Fri, 26 Nov 2021 08:35:12 +0800
> 
> I would like to install the following file:

Please put this into pixel-scroll.el, instead of adding a new file.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 11:06:30 +0800
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Looks OK to me, tho I wonder why you'd want to use a separate file
> > rather than add this directly in `mwheel.el`.
> 
> I think it's out of scope for mwheel.el.
> 
> > Also, see a few more comments below.
> 
> Thanks, fixed and pushed.

Please revert that and merge this into pixel-scroll.el instead.

And in the future, please wait for Lars or myself to respond when you
ask such questions.  Stefan's opinions matter a lot, but he isn't the
maintainer.  Also, leaving some time for others to voice their
opinions is generally a good idea.  We are supposed to be a community,
not a random collection of individuals each one pursuing his/her own
agendas.

Thanks.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 11:12:23 +0800
> 
> Actually, I would really appreciate someone taking a look at this
> problem.
> 
> Enable `better-pixel-scroll-mode', load gnu.org in eww, and try to
> scroll down with a touchpad.  The problem should be fairly obvious at
> that point.

If this only happens on platforms with x-coalesce-scroll-events, then
I cannot help you.  Someone else would need to do it.

And if there are such problems, perhaps they should have been resolved
before the hasty push.

Re: Pixel scrolling support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Thanks, fixed and pushed.

> Please revert that and merge this into pixel-scroll.el instead.

Before I do that, I'd like to ask a small question: should I merge it
into `pixel-scroll-mode' as well, or keep the separate minor mode for
that?

Right now, `pixel-scroll-mode' works by setting
`mwheel-scroll-down-function' and friends, which doesn't quite work when
relying on information in precise wheel events, so I think it would be
best to define a separate mode, where the precise scrolling commands are
directly bound to the wheel events.

> And in the future, please wait for Lars or myself to respond when you
> ask such questions.

Thanks, I'll keep that in mind.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 14:45:46 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Thanks, fixed and pushed.
> 
> > Please revert that and merge this into pixel-scroll.el instead.
> 
> Before I do that, I'd like to ask a small question: should I merge it
> into `pixel-scroll-mode' as well, or keep the separate minor mode for
> that?
> 
> Right now, `pixel-scroll-mode' works by setting
> `mwheel-scroll-down-function' and friends, which doesn't quite work when
> relying on information in precise wheel events, so I think it would be
> best to define a separate mode, where the precise scrolling commands are
> directly bound to the wheel events.

Separate mode should be fine, but we need a good name for it ("better
pixel scroll" is not a good name).

> > And in the future, please wait for Lars or myself to respond when you
> > ask such questions.
> 
> Thanks, I'll keep that in mind.

TIA

Re: Pixel scrolling support

[Po Lu]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Separate mode should be fine, but we need a good name for it ("better
> pixel scroll" is not a good name).

Thanks, how about `pixel-scroll-precise-mode'?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Move-the-precise-pixel-scrolling-feature-to-pixel-sc.patch --]
[-- Type: text/x-patch, Size: 12999 bytes --]

From db8bf63b949ab65e7ed7ff6b9dfbcd5428cc11c4 Mon Sep 17 00:00:00 2001
From: Po Lu <luangruo@yahoo.com>
Date: Fri, 26 Nov 2021 14:51:27 +0800
Subject: [PATCH] Move the precise pixel scrolling feature to pixel-scroll.el

* etc/NEWS: Update NEWS entry for 'pixel-scroll-precise-mode'

* lisp/better-pixel-scroll.el: Remove file.

* src/pixel-scroll.el (x-coalesce-scroll-events): New variable
declaration.
(pixel-scroll-precise-mode-map): New variable.
(pixel-scroll-precise-scroll-down):
(pixel-scroll-precise-scroll-up):
(pixel-scroll-precise): New functions.
(pixel-scroll-precise-mode): New minor mode.
---
 etc/NEWS                    |   2 +-
 lisp/better-pixel-scroll.el | 147 ------------------------------------
 lisp/pixel-scroll.el        | 115 ++++++++++++++++++++++++++++
 3 files changed, 116 insertions(+), 148 deletions(-)
 delete mode 100644 lisp/better-pixel-scroll.el

diff --git a/etc/NEWS b/etc/NEWS
index 329de2f811..af8689ab83 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -94,7 +94,7 @@ This controls the thickness of the external borders of the menu bars
 and pop-up menus.
 
 ---
-** New minor mode 'better-pixel-scroll-mode'.
+** New minor mode 'pixel-scroll-precise-mode'.
 When enabled, using this mode with a capable scroll wheel will result
 in the display being scrolled precisely according to the turning of
 that wheel.
diff --git a/lisp/better-pixel-scroll.el b/lisp/better-pixel-scroll.el
deleted file mode 100644
index c1469108e0..0000000000
--- a/lisp/better-pixel-scroll.el
+++ /dev/null
@@ -1,147 +0,0 @@
-;;; better-pixel-scroll.el --- Pixel scrolling support  -*- lexical-binding:t -*-
-
-;; Copyright (C) 2021 Free Software Foundation, Inc.
-
-;; This file is part of GNU Emacs.
-
-;; GNU Emacs is free software: you can redistribute it and/or modify
-;; it under the terms of the GNU General Public License as published by
-;; the Free Software Foundation, either version 3 of the License, or
-;; (at your option) any later version.
-
-;; GNU Emacs is distributed in the hope that it will be useful,
-;; but WITHOUT ANY WARRANTY; without even the implied warranty of
-;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-;; GNU General Public License for more details.
-
-;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
-
-;;; Commentary:
-
-;; This enables the use of smooth scroll events provided by XInput 2
-;; or NS to scroll the display according to the user's precise turning
-;; of the mouse wheel.
-
-;;; Code:
-
-(require 'mwheel)
-(require 'subr-x)
-
-(defvar x-coalesce-scroll-events)
-
-(defvar better-pixel-scroll-mode-map
-  (let ((map (make-sparse-keymap)))
-    (define-key map [wheel-down] #'better-pixel-scroll)
-    (define-key map [wheel-up] #'better-pixel-scroll)
-    map)
-  "The key map used by `better-pixel-scroll-mode'.")
-
-(defun better-pixel-scroll-scroll-down (delta)
-  "Scroll the current window down by DELTA pixels.
-Note that this function doesn't work if DELTA is larger than
-the height of the current window."
-  (when-let* ((posn (posn-at-point))
-	      (current-y (cdr (posn-x-y posn)))
-	      (min-y (+ (window-tab-line-height)
-		        (window-header-line-height)))
-              (cursor-height (line-pixel-height))
-              (window-height (window-text-height nil t))
-              (next-height (save-excursion
-                             (vertical-motion 1)
-                             (line-pixel-height))))
-    (if (and (> delta 0)
-             (<= cursor-height window-height))
-	(while (< (- current-y min-y) delta)
-	  (vertical-motion 1)
-          (setq current-y (+ current-y
-                             (line-pixel-height)))
-	  (when (eobp)
-	    (error "End of buffer")))
-      (when (< (- (cdr (posn-object-width-height posn))
-                  (cdr (posn-object-x-y posn)))
-               (- window-height next-height))
-        (vertical-motion 1)
-        (setq posn (posn-at-point)
-              current-y (cdr (posn-x-y posn)))
-        (while (< (- current-y min-y) delta)
-	  (vertical-motion 1)
-          (setq current-y (+ current-y
-                             (line-pixel-height)))
-	  (when (eobp)
-	    (error "End of buffer")))))
-    (let* ((desired-pos (posn-at-x-y 0 (+ delta
-					  (window-tab-line-height)
-					  (window-header-line-height))))
-	   (desired-start (posn-point desired-pos))
-	   (desired-vscroll (cdr (posn-object-x-y desired-pos))))
-      (unless (eq (window-start) desired-start)
-        (set-window-start nil desired-start t))
-      (set-window-vscroll nil desired-vscroll t))))
-
-(defun better-pixel-scroll-scroll-up (delta)
-  "Scroll the current window up by DELTA pixels."
-  (when-let* ((max-y (- (window-text-height nil t)
-		        (window-tab-line-height)
-		        (window-header-line-height)))
-	      (posn (posn-at-point))
-	      (current-y (+ (cdr (posn-x-y posn))
-		            (cdr (posn-object-width-height posn)))))
-    (while (< (- max-y current-y) delta)
-      (vertical-motion -1)
-      (setq current-y (- current-y (line-pixel-height)))))
-  (let ((current-vscroll (window-vscroll nil t)))
-    (setq delta (- delta current-vscroll))
-    (set-window-vscroll nil 0 t))
-  (while (> delta 0)
-    (set-window-start nil (save-excursion
-                            (goto-char (window-start))
-                            (when (zerop (vertical-motion -1))
-			      (set-window-vscroll nil 0)
-			      (signal 'beginning-of-buffer nil))
-                            (setq delta (- delta (line-pixel-height)))
-                            (point))
-		      t))
-  (when (< delta 0)
-    (when-let* ((desired-pos (posn-at-x-y 0 (+ (- delta)
-					  (window-tab-line-height)
-					  (window-header-line-height))))
-	        (desired-start (posn-point desired-pos))
-	        (desired-vscroll (cdr (posn-object-x-y desired-pos))))
-      (unless (eq (window-start) desired-start)
-        (set-window-start nil desired-start t))
-      (set-window-vscroll nil desired-vscroll t))))
-
-(defun better-pixel-scroll (event &optional arg)
-  "Scroll the display according to EVENT.
-Take into account any pixel deltas in EVENT to scroll the display
-according to the user's turning the mouse wheel.  If EVENT does
-not have precise scrolling deltas, call `mwheel-scroll' instead.
-ARG is passed to `mwheel-scroll', should that be called."
-  (interactive (list last-input-event current-prefix-arg))
-  (let ((window (mwheel-event-window event)))
-    (if (and (nth 4 event)
-             (zerop (window-hscroll window)))
-        (let ((delta (round (cdr (nth 4 event)))))
-          (if (> (abs delta) (window-text-height window t))
-              (mwheel-scroll event arg)
-            (with-selected-window window
-              (if (< delta 0)
-	          (better-pixel-scroll-scroll-down (- delta))
-                (better-pixel-scroll-scroll-up delta)))))
-      (mwheel-scroll event arg))))
-
-;;;###autoload
-(define-minor-mode better-pixel-scroll-mode
-  "Toggle pixel scrolling.
-When enabled, this minor mode allows to scroll the display
-precisely, according to the turning of the mouse wheel."
-  :global t
-  :group 'mouse
-  :keymap better-pixel-scroll-mode-map
-  (setq x-coalesce-scroll-events
-        (not better-pixel-scroll-mode)))
-
-(provide 'better-pixel-scroll)
-
-;;; better-pixel-scroll.el ends here.
diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
index 249484cf58..9ea92fe903 100644
--- a/lisp/pixel-scroll.el
+++ b/lisp/pixel-scroll.el
@@ -67,6 +67,7 @@
 ;;; Code:
 
 (require 'mwheel)
+(require 'subr-x)
 
 (defvar pixel-wait 0
   "Idle time on each step of pixel scroll specified in second.
@@ -90,6 +91,15 @@ pixel-dead-time
 (defvar pixel-last-scroll-time 0
   "Time when the last scrolling was made, in second since the epoch.")
 
+(defvar x-coalesce-scroll-events)
+
+(defvar pixel-scroll-precise-mode-map
+  (let ((map (make-sparse-keymap)))
+    (define-key map [wheel-down] #'pixel-scroll-precise)
+    (define-key map [wheel-up] #'pixel-scroll-precise)
+    map)
+  "The key map used by `pixel-scroll-precise-mode'.")
+
 (defun pixel-scroll-in-rush-p ()
   "Return non-nil if next scroll should be non-smooth.
 When scrolling request is delivered soon after the previous one,
@@ -354,5 +364,110 @@ pixel-scroll-down-and-set-window-vscroll
   (set-window-start nil (pixel-point-at-unseen-line) t)
   (set-window-vscroll nil vscroll t))
 
+(defun pixel-scroll-precise-scroll-down (delta)
+  "Scroll the current window down by DELTA pixels.
+Note that this function doesn't work if DELTA is larger than
+the height of the current window."
+  (when-let* ((posn (posn-at-point))
+	      (current-y (cdr (posn-x-y posn)))
+	      (min-y (+ (window-tab-line-height)
+		        (window-header-line-height)))
+              (cursor-height (line-pixel-height))
+              (window-height (window-text-height nil t))
+              (next-height (save-excursion
+                             (vertical-motion 1)
+                             (line-pixel-height))))
+    (if (and (> delta 0)
+             (<= cursor-height window-height))
+	(while (< (- current-y min-y) delta)
+	  (vertical-motion 1)
+          (setq current-y (+ current-y
+                             (line-pixel-height)))
+	  (when (eobp)
+	    (error "End of buffer")))
+      (when (< (- (cdr (posn-object-width-height posn))
+                  (cdr (posn-object-x-y posn)))
+               (- window-height next-height))
+        (vertical-motion 1)
+        (setq posn (posn-at-point)
+              current-y (cdr (posn-x-y posn)))
+        (while (< (- current-y min-y) delta)
+	  (vertical-motion 1)
+          (setq current-y (+ current-y
+                             (line-pixel-height)))
+	  (when (eobp)
+	    (error "End of buffer")))))
+    (let* ((desired-pos (posn-at-x-y 0 (+ delta
+					  (window-tab-line-height)
+					  (window-header-line-height))))
+	   (desired-start (posn-point desired-pos))
+	   (desired-vscroll (cdr (posn-object-x-y desired-pos))))
+      (unless (eq (window-start) desired-start)
+        (set-window-start nil desired-start t))
+      (set-window-vscroll nil desired-vscroll t))))
+
+(defun pixel-scroll-precise-scroll-up (delta)
+  "Scroll the current window up by DELTA pixels."
+  (when-let* ((max-y (- (window-text-height nil t)
+		        (window-tab-line-height)
+		        (window-header-line-height)))
+	      (posn (posn-at-point))
+	      (current-y (+ (cdr (posn-x-y posn))
+		            (cdr (posn-object-width-height posn)))))
+    (while (< (- max-y current-y) delta)
+      (vertical-motion -1)
+      (setq current-y (- current-y (line-pixel-height)))))
+  (let ((current-vscroll (window-vscroll nil t)))
+    (setq delta (- delta current-vscroll))
+    (set-window-vscroll nil 0 t))
+  (while (> delta 0)
+    (set-window-start nil (save-excursion
+                            (goto-char (window-start))
+                            (when (zerop (vertical-motion -1))
+			      (set-window-vscroll nil 0)
+			      (signal 'beginning-of-buffer nil))
+                            (setq delta (- delta (line-pixel-height)))
+                            (point))
+		      t))
+  (when (< delta 0)
+    (when-let* ((desired-pos (posn-at-x-y 0 (+ (- delta)
+					  (window-tab-line-height)
+					  (window-header-line-height))))
+	        (desired-start (posn-point desired-pos))
+	        (desired-vscroll (cdr (posn-object-x-y desired-pos))))
+      (unless (eq (window-start) desired-start)
+        (set-window-start nil desired-start t))
+      (set-window-vscroll nil desired-vscroll t))))
+
+(defun pixel-scroll-precise (event &optional arg)
+  "Scroll the display according to EVENT.
+Take into account any pixel deltas in EVENT to scroll the display
+according to the user's turning the mouse wheel.  If EVENT does
+not have precise scrolling deltas, call `mwheel-scroll' instead.
+ARG is passed to `mwheel-scroll', should that be called."
+  (interactive (list last-input-event current-prefix-arg))
+  (let ((window (mwheel-event-window event)))
+    (if (and (nth 4 event)
+             (zerop (window-hscroll window)))
+        (let ((delta (round (cdr (nth 4 event)))))
+          (if (> (abs delta) (window-text-height window t))
+              (mwheel-scroll event arg)
+            (with-selected-window window
+              (if (< delta 0)
+	          (pixel-scroll-precise-scroll-down (- delta))
+                (pixel-scroll-precise-scroll-up delta)))))
+      (mwheel-scroll event arg))))
+
+;;;###autoload
+(define-minor-mode pixel-scroll-precise-mode
+  "Toggle pixel scrolling.
+When enabled, this minor mode allows to scroll the display
+precisely, according to the turning of the mouse wheel."
+  :global t
+  :group 'mouse
+  :keymap pixel-scroll-precise-mode-map
+  (setq x-coalesce-scroll-events
+        (not pixel-scroll-precise-mode)))
+
 (provide 'pixel-scroll)
 ;;; pixel-scroll.el ends here
-- 
2.33.1

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 15:01:57 +0800
> 
> > Separate mode should be fine, but we need a good name for it ("better
> > pixel scroll" is not a good name).
> 
> Thanks, how about `pixel-scroll-precise-mode'?

pixel-scroll-precision-mode sounds better to me.

> -** New minor mode 'better-pixel-scroll-mode'.
> +** New minor mode 'pixel-scroll-precise-mode'.
>  When enabled, using this mode with a capable scroll wheel will result
>  in the display being scrolled precisely according to the turning of
>  that wheel.

This text doesn't really describe what the mode does.  It basically
says something like "pixel-scroll-precise-mode scrolls precisely".
the main part that was left unexplained is "according to the turning of
that wheel", and specifically the "according" part.

> +(defun pixel-scroll-precise-scroll-down (delta)
> +  "Scroll the current window down by DELTA pixels.
> +Note that this function doesn't work if DELTA is larger than
> +the height of the current window."

What is the problem with scrolling by more than the window's height?

> +	  (when (eobp)
> +	    (error "End of buffer")))

I think you should detect the EOB condition early on and simply not
scroll at all in that case.

> +(defun pixel-scroll-precise (event &optional arg)
> +  "Scroll the display according to EVENT.

This sentence should include something to indicate the "precise"
feature.  Otherwise it is too general, indistinguishable from any
other scroll command.

> +Take into account any pixel deltas in EVENT to scroll the display
> +according to the user's turning the mouse wheel.  If EVENT does
> +not have precise scrolling deltas, call `mwheel-scroll' instead.

This describes what the code does, not what the user should expect in
terms of the effect on the screen.

> +ARG is passed to `mwheel-scroll', should that be called."

Likewise: the description of ARG should be similar to how we describe
the effect of prefix arg in other similar commands.

> +;;;###autoload
> +(define-minor-mode pixel-scroll-precise-mode
> +  "Toggle pixel scrolling.
> +When enabled, this minor mode allows to scroll the display
> +precisely, according to the turning of the mouse wheel."

Shouldn't this say something about "setting the variable doesn't have
any effect"?

And what about horizontal scrolling?

Thanks.

Re: Pixel scrolling support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> pixel-scroll-precision-mode sounds better to me.

Hmm, I don't think that's quite right, but I can't explain how it's not.
I think it would be best to keep it as `pixel-scroll-precise-mode'.

>> -** New minor mode 'better-pixel-scroll-mode'.
>> +** New minor mode 'pixel-scroll-precise-mode'.
>>  When enabled, using this mode with a capable scroll wheel will result
>>  in the display being scrolled precisely according to the turning of
>>  that wheel.

> This text doesn't really describe what the mode does.  It basically
> says something like "pixel-scroll-precise-mode scrolls precisely".
> the main part that was left unexplained is "according to the turning of
> that wheel", and specifically the "according" part.

How about this: "When enabled, you can scroll the display up or down by
individual pixels in a way that corresponds with the movement of your
mouse wheel, if supported by the mouse wheel."?

> What is the problem with scrolling by more than the window's height?

Basically, we use `posn-at-x-y' to find the window start and the vscroll
that's wanted, which doesn't work when y is outside the window.

> I think you should detect the EOB condition early on and simply not
> scroll at all in that case.

I couldn't find a way to know if scrolling will result in EOB before it
actually happens.

>> +(defun pixel-scroll-precise (event &optional arg)
>> +  "Scroll the display according to EVENT.

> This sentence should include something to indicate the "precise"
> feature.  Otherwise it is too general, indistinguishable from any
> other scroll command.

Hmm, how about "Scroll the display by pixels according to EVENT"?

>> +Take into account any pixel deltas in EVENT to scroll the display
>> +according to the user's turning the mouse wheel.  If EVENT does
>> +not have precise scrolling deltas, call `mwheel-scroll' instead.

> This describes what the code does, not what the user should expect in
> terms of the effect on the screen.

  "Scroll the display vertically by pixels according to EVENT.
Move the display up or down by the pixel deltas in EVENT to
scroll the display according to the user's turning the mouse
wheel."

How's this instead?

>> +ARG is passed to `mwheel-scroll', should that be called."

> Likewise: the description of ARG should be similar to how we describe
> the effect of prefix arg in other similar commands.

Actually, this command doesn't handle hscroll, so ARG seems to be
pointless.  Removed, thanks.

> Shouldn't this say something about "setting the variable doesn't have
> any effect"?

Yes, my bad.

> And what about horizontal scrolling?

It doesn't handle horizontal scrolling, so I changed the doc strings to
specify that the display is scrolled vertically by these commands.

Thanks.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 17:29:25 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > pixel-scroll-precision-mode sounds better to me.
> 
> Hmm, I don't think that's quite right, but I can't explain how it's not.
> I think it would be best to keep it as `pixel-scroll-precise-mode'.

That name tells me that the _mode_ is "precise", but that's not what you
want to convey.  The scrolling is precise, not the mode.

An alternative would be something like pixel-scroll-smoothly-mode.

> >> -** New minor mode 'better-pixel-scroll-mode'.
> >> +** New minor mode 'pixel-scroll-precise-mode'.
> >>  When enabled, using this mode with a capable scroll wheel will result
> >>  in the display being scrolled precisely according to the turning of
> >>  that wheel.
> 
> > This text doesn't really describe what the mode does.  It basically
> > says something like "pixel-scroll-precise-mode scrolls precisely".
> > the main part that was left unexplained is "according to the turning of
> > that wheel", and specifically the "according" part.
> 
> How about this: "When enabled, you can scroll the display up or down by
> individual pixels in a way that corresponds with the movement of your
> mouse wheel, if supported by the mouse wheel."?

"By individual pixels" is not really accurate, is it?  Maybe "at pixel
resolution".  And now the question becomes "how is this different from
pixel-scroll-mode"?  Which is a good question regardless of NEWS, btw.

> > What is the problem with scrolling by more than the window's height?
> 
> Basically, we use `posn-at-x-y' to find the window start and the vscroll
> that's wanted, which doesn't work when y is outside the window.

Did you try to use vertical-motion to help you?  Or maybe I don't
understand the problem, since the vertical dimensions of a window are
known in pixels, so what exactly is the problem to determine the
window start when it is outside of the window?  scroll-down-command
does that without any problems.

> > I think you should detect the EOB condition early on and simply not
> > scroll at all in that case.
> 
> I couldn't find a way to know if scrolling will result in EOB before it
> actually happens.

Did you try using pos-visible-in-window-p with POS argument passed as
t?

> >> +(defun pixel-scroll-precise (event &optional arg)
> >> +  "Scroll the display according to EVENT.
> 
> > This sentence should include something to indicate the "precise"
> > feature.  Otherwise it is too general, indistinguishable from any
> > other scroll command.
> 
> Hmm, how about "Scroll the display by pixels according to EVENT"?

Better.

> >> +Take into account any pixel deltas in EVENT to scroll the display
> >> +according to the user's turning the mouse wheel.  If EVENT does
> >> +not have precise scrolling deltas, call `mwheel-scroll' instead.
> 
> > This describes what the code does, not what the user should expect in
> > terms of the effect on the screen.
> 
>   "Scroll the display vertically by pixels according to EVENT.
> Move the display up or down by the pixel deltas in EVENT to
> scroll the display according to the user's turning the mouse
> wheel."
> 
> How's this instead?

Where did the "call `mwheel-scroll'" part disappear?  If it was
important to say that, why there's no reflection of that in the new
text?

> > And what about horizontal scrolling?
> 
> It doesn't handle horizontal scrolling, so I changed the doc strings to
> specify that the display is scrolled vertically by these commands.

I'm asking why don't we support pixel-resolution horizontal scrolling
in this mode, although the underlying infrastructure does report
pixel-resolution mouse-wheel rotation in the horizontal direction?

Re: Pixel scrolling support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That name tells me that the _mode_ is "precise", but that's not what you
> want to convey.  The scrolling is precise, not the mode.
>
> An alternative would be something like pixel-scroll-smoothly-mode.

Hmm, reasonable, "precision" makes sense now.

>> How about this: "When enabled, you can scroll the display up or down by
>> individual pixels in a way that corresponds with the movement of your
>> mouse wheel, if supported by the mouse wheel."?

> "By individual pixels" is not really accurate, is it?  Maybe "at pixel
> resolution".  And now the question becomes "how is this different from
> pixel-scroll-mode"?  Which is a good question regardless of NEWS, btw.

pixel-scroll-mode still scrolls by lines, it just tries to animate each
line movement.  It's very unpleasant to use that with a precision scroll
wheel.

>> Basically, we use `posn-at-x-y' to find the window start and the vscroll
>> that's wanted, which doesn't work when y is outside the window.

> Did you try to use vertical-motion to help you?  Or maybe I don't
> understand the problem, since the vertical dimensions of a window are
> known in pixels, so what exactly is the problem to determine the
> window start when it is outside of the window?  scroll-down-command
> does that without any problems.

I use `posn-at-x-y' to determine the position closest to the first line
to be displayed on screen after the window is vscrolled by DELTA.

Afterwards, I set the window start to that position, and set the vscroll
to the object Y in the position list that is returned, which contains
the number of pixels that are still left after window start has been
adjusted.

I don't see how `vertical-motion' could help.

>> > I think you should detect the EOB condition early on and simply not
>> > scroll at all in that case.
>> 
>> I couldn't find a way to know if scrolling will result in EOB before it
>> actually happens.

> Did you try using pos-visible-in-window-p with POS argument passed as
> t?

But that doesn't take into account the delta by which the window is
being scrolled, right?

>> >> +(defun pixel-scroll-precise (event &optional arg)
>> >> +  "Scroll the display according to EVENT.
>> 
>> > This sentence should include something to indicate the "precise"
>> > feature.  Otherwise it is too general, indistinguishable from any
>> > other scroll command.
>> 
>> Hmm, how about "Scroll the display by pixels according to EVENT"?
>
> Better.
>
>> >> +Take into account any pixel deltas in EVENT to scroll the display
>> >> +according to the user's turning the mouse wheel.  If EVENT does
>> >> +not have precise scrolling deltas, call `mwheel-scroll' instead.
>> 
>> > This describes what the code does, not what the user should expect in
>> > terms of the effect on the screen.
>> 
>>   "Scroll the display vertically by pixels according to EVENT.
>> Move the display up or down by the pixel deltas in EVENT to
>> scroll the display according to the user's turning the mouse
>> wheel."
>> 
>> How's this instead?

> Where did the "call `mwheel-scroll'" part disappear?  If it was
> important to say that, why there's no reflection of that in the new
> text?

As ARG is gone, I don't think it's important to mention that
`mwheel-scroll' is called anymore.

> I'm asking why don't we support pixel-resolution horizontal scrolling
> in this mode, although the underlying infrastructure does report
> pixel-resolution mouse-wheel rotation in the horizontal direction?

AFAIU, redisplay doesn't support pixel-resolution hscroll, so while
wheel rotation is reported in that direction, there is no way to scroll
the display horizontally in a pixel-wise fashion.

Thanks in advance.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 19:38:10 +0800
> 
> >> How about this: "When enabled, you can scroll the display up or down by
> >> individual pixels in a way that corresponds with the movement of your
> >> mouse wheel, if supported by the mouse wheel."?
> 
> > "By individual pixels" is not really accurate, is it?  Maybe "at pixel
> > resolution".  And now the question becomes "how is this different from
> > pixel-scroll-mode"?  Which is a good question regardless of NEWS, btw.
> 
> pixel-scroll-mode still scrolls by lines, it just tries to animate each
> line movement.  It's very unpleasant to use that with a precision scroll
> wheel.

Well, that sounds like a good description of the difference (minus the
"unpleasant" part) to have in the NEWS entry.

> >> Basically, we use `posn-at-x-y' to find the window start and the vscroll
> >> that's wanted, which doesn't work when y is outside the window.
> 
> > Did you try to use vertical-motion to help you?  Or maybe I don't
> > understand the problem, since the vertical dimensions of a window are
> > known in pixels, so what exactly is the problem to determine the
> > window start when it is outside of the window?  scroll-down-command
> > does that without any problems.
> 
> I use `posn-at-x-y' to determine the position closest to the first line
> to be displayed on screen after the window is vscrolled by DELTA.

How do you know which line is "the first line to be displayed on
screen after the window is vscrolled by DELTA"?  That's the bit I'm
missing, I think.

> >> > I think you should detect the EOB condition early on and simply not
> >> > scroll at all in that case.
> >> 
> >> I couldn't find a way to know if scrolling will result in EOB before it
> >> actually happens.
> 
> > Did you try using pos-visible-in-window-p with POS argument passed as
> > t?
> 
> But that doesn't take into account the delta by which the window is
> being scrolled, right?

What is "the delta by which the window is being scrolled"?  Is that
the window's vscroll or is that something else?

> >>   "Scroll the display vertically by pixels according to EVENT.
> >> Move the display up or down by the pixel deltas in EVENT to
> >> scroll the display according to the user's turning the mouse
> >> wheel."
> >> 
> >> How's this instead?
> 
> > Where did the "call `mwheel-scroll'" part disappear?  If it was
> > important to say that, why there's no reflection of that in the new
> > text?
> 
> As ARG is gone, I don't think it's important to mention that
> `mwheel-scroll' is called anymore.

See my question about the difference between mwheel and this mode: it
might be important after all.

> > I'm asking why don't we support pixel-resolution horizontal scrolling
> > in this mode, although the underlying infrastructure does report
> > pixel-resolution mouse-wheel rotation in the horizontal direction?
> 
> AFAIU, redisplay doesn't support pixel-resolution hscroll

Of course, it does.  It might not be exposed to Lisp (I didn't look
closely enough), but it is certainly supported on the C level.

Re: Pixel scrolling support

[Stephen Berman]

On Fri, 26 Nov 2021 19:38:10 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> That name tells me that the _mode_ is "precise", but that's not what you
>> want to convey.  The scrolling is precise, not the mode.
>>
>> An alternative would be something like pixel-scroll-smoothly-mode.
>
> Hmm, reasonable, "precision" makes sense now.

How about pixel-scroll-precisely-mode?  Or pixel-precise-scrolling-mode?

Steve Berman

Re: Pixel scrolling support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> pixel-scroll-mode still scrolls by lines, it just tries to animate each
>> line movement.  It's very unpleasant to use that with a precision scroll
>> wheel.

> Well, that sounds like a good description of the difference (minus the
> "unpleasant" part) to have in the NEWS entry.

I'll add that to the NEWS entry, thanks.

>> I use `posn-at-x-y' to determine the position closest to the first line
>> to be displayed on screen after the window is vscrolled by DELTA.

> How do you know which line is "the first line to be displayed on
> screen after the window is vscrolled by DELTA"?  That's the bit I'm
> missing, I think.

Basically, the first line that's displayed in the window (which might
not be the line at window start if the window is vscrolled).

> What is "the delta by which the window is being scrolled"?  Is that
> the window's vscroll or is that something else?

It's the pixel delta by which the window will be scrolled vertically.

> Of course, it does.  It might not be exposed to Lisp (I didn't look
> closely enough), but it is certainly supported on the C level.

Hmm, it would be great to expose that to Lisp, as right now
`set-window-hscroll' only accepts columns and not pixels.

Thanks.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 20:09:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I use `posn-at-x-y' to determine the position closest to the first line
> >> to be displayed on screen after the window is vscrolled by DELTA.
> 
> > How do you know which line is "the first line to be displayed on
> > screen after the window is vscrolled by DELTA"?  That's the bit I'm
> > missing, I think.
> 
> Basically, the first line that's displayed in the window (which might
> not be the line at window start if the window is vscrolled).

If that position is outside the window, you should be able to use
window-text-pixel-size to get the information.

> > What is "the delta by which the window is being scrolled"?  Is that
> > the window's vscroll or is that something else?
> 
> It's the pixel delta by which the window will be scrolled vertically.

Sorry, I don't understand how this is relevant pos-visible-in-window-p
can tell you the pixel coordinates of EOB if it is inside the window.
If the EOB is inside the window, you should not scroll at all and
return immediately, so as to avoid the annoying error.

> > Of course, it does.  It might not be exposed to Lisp (I didn't look
> > closely enough), but it is certainly supported on the C level.
> 
> Hmm, it would be great to expose that to Lisp, as right now
> `set-window-hscroll' only accepts columns and not pixels.

Patches welcome.

Re: Pixel scrolling support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> If that position is outside the window, you should be able to use
> window-text-pixel-size to get the information.

Hmm, I will look into that, thanks.

> Sorry, I don't understand how this is relevant pos-visible-in-window-p
> can tell you the pixel coordinates of EOB if it is inside the window.
> If the EOB is inside the window, you should not scroll at all and
> return immediately, so as to avoid the annoying error.

Actually, I think we should just signal `end-of-buffer' in that case.
That is a user facing error after all, no different from the other
places where user commands signal `end-of-buffer'.

Re: Pixel scrolling support

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Hmm, I will look into that, thanks.

But the limitation of not being able to pixel-scroll more than the
height of the window at once aside, I would like to install this change
with the other improvements you mentioned earlier.

Is that OK with you?  Thanks.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 20:49:37 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Hmm, I will look into that, thanks.
> 
> But the limitation of not being able to pixel-scroll more than the
> height of the window at once aside, I would like to install this change
> with the other improvements you mentioned earlier.
> 
> Is that OK with you?  Thanks.

yes.  But if you don't intend to work on larger scrolls soon, please
add a FIXME there.

Re: Pixel scrolling support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> yes.  But if you don't intend to work on larger scrolls soon, please
> add a FIXME there.

Thanks.

Re: Pixel scrolling support

[Stefan Monnier]

Po Lu [2021-11-26 11:06:30] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Looks OK to me, tho I wonder why you'd want to use a separate file
>> rather than add this directly in `mwheel.el`.
> I think it's out of scope for mwheel.el.

That sounds odd, seeing how it binds the same kind of events and
delegates to mwheel when the pixel info is not available.
I see someone else proposed `pixel-scroll.el`, which sounds OK as well.

We'll presumably also want to enable it by default eventually.

Also the discussion about it being "unEmacsy" because the user has no
control about the behavior suggest the code should obey
`mouse-wheel-scroll-amount`, `mouse-wheel-progressive-speed`, and
probably others.

Maybe its code should actually be split into `mwheel.el` and
`pixel-scroll.el`, but having its own dedicated file doesn't seem right.


        Stefan

Re: Pixel scrolling support

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> We'll presumably also want to enable it by default eventually.

Yes, but someone will have to make it work correctly with tall images
first, 100% of the time.

I am at a loss with respect to that.

Thanks.

Re: Pixel scrolling support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 21:41:15 +0800
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > We'll presumably also want to enable it by default eventually.
> 
> Yes, but someone will have to make it work correctly with tall images
> first, 100% of the time.
> 
> I am at a loss with respect to that.

I thought you said it does work with images, just slowly (which hints
on high CPU load)?

Re: Pixel scrolling support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> I am at a loss with respect to that.

> I thought you said it does work with images, just slowly (which hints
> on high CPU load)?

It works with images, but not very large images that are taller than the
window they are displayed in.

bug#52120 is a related issue that manifests itself during pixel
scrolling, but it's not related to the problem here.

I have tracked it down to some deficiency in the cairo code, and I will
fix it once I get time.

Thanks.

Re: Pixel scrolling support

[Michael Heerdegen]

Po Lu <luangruo@yahoo.com> writes:

> I would like to install the following file: [...]

I like the new pixel-scroll-precision-mode very much! - but there is a
problem with it:

#+begin_src emacs-lisp
(define-minor-mode pixel-scroll-precision-mode
  "Toggle pixel scrolling.
When enabled, this minor mode allows to scroll the display
precisely, according to the turning of the mouse wheel."
  :global t
  :group 'mouse
  :keymap pixel-scroll-precision-mode-map
  ...)
#+end_src

This overwrites the mwheel bindings in any buffer with pixel-scroll
functions, and since it's a minor-mode, it wins over major-mode
bindings.

For example, osm.el (in Gnu Elpa) uses the mouse wheel to zoom the map.
Since `pixel-scroll-precision-mode' is a global minor mode, it is not
even trivial to work around this problem in one's config.

TIA,

Michael.

Re: Pixel scrolling support

[Po Lu]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> This overwrites the mwheel bindings in any buffer with pixel-scroll
> functions, and since it's a minor-mode, it wins over major-mode
> bindings.
>
> For example, osm.el (in Gnu Elpa) uses the mouse wheel to zoom the map.
> Since `pixel-scroll-precision-mode' is a global minor mode, it is not
> even trivial to work around this problem in one's config.

That's not the problem, since osm.el doesn't bind itself to mouse
wheels, but uses the mwheel scrolling function variables instead.

Precision scrolling must bind itself to wheel events directly, since it
needs information that isn't available to the mwheel-scroll functions.

osm.el should be modified to bind its zooming commands to the mouse
wheels themselves instead of using the mwheel variables.

pixel scroll vs. osm (was: Pixel scrolling support)

[Michael Heerdegen]

Po Lu <luangruo@yahoo.com> writes:

> Precision scrolling must bind itself to wheel events directly, since it
> needs information that isn't available to the mwheel-scroll functions.
>
> osm.el should be modified to bind its zooming commands to the mouse
> wheels themselves instead of using the mwheel variables.

Daniel, we had already talked - you were not eager to work around this
problem in osm.el - how can we find a solution?

TIA,

Michael.

Re: pixel scroll vs. osm

[Po Lu]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Daniel, we had already talked - you were not eager to work around this
> problem in osm.el - how can we find a solution?

It is impossible to change pixel-scroll-precision to work from one of
the mwheel scrolling functions, so the solution is for osm.el to bind
its commands functions to `wheel-up' and `wheel-down' directly.

Doing so will also provide the necessary information for "pixel-wise"
zooming.

Re: pixel scroll vs. osm

[Michael Heerdegen]

Po Lu <luangruo@yahoo.com> writes:

> It is impossible to change pixel-scroll-precision to work from one of
> the mwheel scrolling functions, so the solution is for osm.el to bind
> its commands functions to `wheel-up' and `wheel-down' directly.

Thought from the other end: Is there (or should there be) an official
way to disable pixel-scroll-precision-mode in certain buffers?  Doing

  (setq-local pixel-scroll-precision-mode nil)

works for me and fixes the issue (but doesn't look like a solution I
would recommend to others).

Michael.

Re: pixel scroll vs. osm

[Michael Heerdegen]

Po Lu <luangruo@yahoo.com> writes:

> It is impossible to change pixel-scroll-precision to work from one of
> the mwheel scrolling functions, so the solution is for osm.el to bind
> its commands functions to `wheel-up' and `wheel-down' directly.
>
> Doing so will also provide the necessary information for "pixel-wise"
> zooming.

One unpleasant side effect of that is the fact that
`mwheel-scroll-up-function' and `mwheel-scroll-down-function' are
bypassed, and their values don't reflect the scrolling behavior.

I guess, if these variables can't carry the commands that will likely be
used to scroll with the mouse in future Emacsen by lots of users, their
semantics should either be enhanced or they should be removed.

Michael.

Re: pixel scroll vs. osm

[Po Lu]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> One unpleasant side effect of that is the fact that
> `mwheel-scroll-up-function' and `mwheel-scroll-down-function' are
> bypassed, and their values don't reflect the scrolling behavior.
>
> I guess, if these variables can't carry the commands that will likely be
> used to scroll with the mouse in future Emacsen by lots of users, their
> semantics should either be enhanced or they should be removed.

Those two functions are used by mwheel.el -- not by the precision
scrolling code, which completely replaces mwheel.el.