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 06:17:49 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>   (push (point) point-list)
> >>   (push (count-lines 1 (point)) current-line-list)
> >>   ;; Call original recenter for final adjustment.
> >>   (recenter 0 t)
> >>   (push (point) point-list)
> >>   (push (count-lines 1 (point)) current-line-list))
> >> 
> >> point-list ; -> 757 757 757 757
> >> current-line-list ; -> 21 21 21 21
> >
> > Try harder, that's not all the truth.  In particular, what happens
> > during the interpolation is not shown.
> 
> Why does it need to matter? Right before calling recenter, the point is
> at 757, as you can see from point-list in my test.

That's not what I see in my testing.  Point usually is there, but not
always.  The whole recipe is not deterministic, as I told many
messages ago.

> > In addition, the way 'recenter' works, it is not guaranteed that point
> > will end up on the line you ask it to place point.  It's a "best
> > effort", no more.
> 
> May you please explain how I am supposed to know this from reading the
> docstring?

Would knowing that convince you that your snippet is based on shaky
grounds?

> And even then, when scrolling current line to be on the top (which is
> what (recenter 0 t) supposed to do), as a user, I will be surprised that
> the current line remains at line 21! - what kind of "best effort" is
> that when the result if off by 21 lines? surely, Emacs can do better.

You again assume that you know what is the "current line" when
'recenter' is called.  Given that the code immediately before that
scrolls the window, what is the "current line" is not well defined.