Re: scroll-down with pixel transition

[Eli Zaretskii]

> Date: Tue, 11 Apr 2017 07:24:17 +0900 (JST)
> Cc: address@hidden, address@hidden
> From: Tak Kunihiro <address@hidden>
> 
> >> It works.
> >> Is there a way to visually hide the overshoot on (scroll-down 1)?
> > 
> > I don't understand the question.  The display is only refreshed when
> > you call sit-for, so you have complete control of that already, and
> > AFAICS the code does what you told it to do.  Am I missing something?
> 
> In Emacs around me (25.1 on Mac, 25.1 on Windows), the following lines
> give me overshoot for each scroll-down.  Is not the case for you?
> 
> (dotimes (ii 10)
>   (scroll-down 1)
>   (set-window-vscroll nil (1- (frame-char-height)) t) (sit-for 0.05)
>   (dolist (vs (reverse (number-sequence 0 (- (frame-char-height) 2))))
>     (set-window-vscroll nil vs t) (sit-for 0.05)))

I'm still not sure what you mean by "overshoot", but if that's the
extra full-line scroll for each of the 10 iterations, then you see the
same in the snippet you shown that scrolls in the other direction, if
you look carefully.

The current display code doesn't like starting a window with a
partially visible line, so it zeroes out the vscroll if that produces
a fully-visible line at the window start.  E.g., try this:

  (progn
    (vertical-motion 1)
    (dolist (vs (number-sequence 1 (- (frame-char-height) 6)))
      (set-window-vscroll nil vs t) (sit-for 0.001)))

This ends up with the first window line partially visible, but as soon
as you move the cursor (triggering a redisplay cycle, just like
sit-for does), Emacs zeroes the window's vscroll to make that line
fully visible.  Changing that (probably as some special optional mode)
will require changes in the display engine on the C level and in
probably also in the line-moving commands in simple.el.  Patches
welcome.