Re: Pixel scrolling support

[Eli Zaretskii <eliz@gnu.org>]

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