Re: Pixel scrolling support

[Po Lu <luangruo@yahoo.com>]

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.