bug#70386: 30.0.50; (recenter 0 t) does not put point on top of the window

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sun, 12 May 2024 09:23:17 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I am mostly concerned about the case when the line _does not_ move to
> >> window's top. The other case is what I observed in the past as well. It
> >> is only the case when nothing is moved between begin/end states that
> >> appeared recently.
> >
> > It never happens that "nothing is moved" here.  What I see is that the
> > window is scrolled as expected, and then scrolled (or recentered?)
> > back.
> 
> That's what I mean by "does not move to window's top". I expect
> recentering to not move things back to the initial state but instead to
> set the point at least close to the top of the window.

Why do you think it's the call to 'recenter' which does it?  Any solid
evidence to confirm that?

Also, are you familiar with how 'recenter' works in Emacs?  The call
to the function doesn't scroll the text, it only asks (gently) that
redisplay does.  And redisplay kicks in when your snippet finished
running, and Emacs is back in its main loop.

On top of that, your snippet calls pixel-scroll-precision-interpolate,
which runs a loop which itself calls redisplay, and which waits for 1
msec between loop iterations (something that on some system is
impossible, and you get either no waiting or a much larger wait
period, like 10 msec).  Should we be surprised that the results are
shaky at best?