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

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

[Ihor Radchenko]

Consider the following reproducer:

1. emacs -Q
2. Insert the following into scratch buffer and put point at "recenter"

(progn
  (require 'pixel-scroll)
  (pixel-scroll-precision-interpolate
   (* -1 (line-pixel-height)
      (max 0 (- (count-screen-lines (window-start) (point)) 2)))
   nil 1)
  ;; Call original recenter for final adjustment.
  (recenter 0 t))

3. M-x eval-buffer
4. Observe that scroll is not set to line 0, despite calling `recenter'

Changing (recenter 0 t) to (recenter 1 t) makes scrolling work as
expected.

This is on the latest master. I started seeing it only today, after
pulling the latest main.

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-04-14 built on localhost
Repository revision: 99c86454cdd2720dd23393e4ffd94f8d27b784ca
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Gentoo Linux

Configured using:
 'configure 'CFLAGS= -g3'
 JAVAC=/etc/java-config-2/current-system-vm/bin/javac'


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Sun, 14 Apr 2024 16:33:48 +0000
> 
> Consider the following reproducer:
> 
> 1. emacs -Q
> 2. Insert the following into scratch buffer and put point at "recenter"

Which "recenter": the one in the comment or the one in (recenter 0 t) ?

> (progn
>   (require 'pixel-scroll)
>   (pixel-scroll-precision-interpolate
>    (* -1 (line-pixel-height)
>       (max 0 (- (count-screen-lines (window-start) (point)) 2)))
>    nil 1)
>   ;; Call original recenter for final adjustment.
>   (recenter 0 t))
> 
> 3. M-x eval-buffer
> 4. Observe that scroll is not set to line 0, despite calling `recenter'

I don't think I understand what you mean by "scroll is not set to line
0".  Please explain in more detail what you expected to happen (and
why), and what did happen.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1. emacs -Q
>> 2. Insert the following into scratch buffer and put point at "recenter"
>
> Which "recenter": the one in the comment or the one in (recenter 0 t) ?

The "(recenter 0 t))" line.

>> (progn
>>   (require 'pixel-scroll)
>>   (pixel-scroll-precision-interpolate
>>    (* -1 (line-pixel-height)
>>       (max 0 (- (count-screen-lines (window-start) (point)) 2)))
>>    nil 1)
>>   ;; Call original recenter for final adjustment.
>>   (recenter 0 t))
>> 
>> 3. M-x eval-buffer
>> 4. Observe that scroll is not set to line 0, despite calling `recenter'
>
> I don't think I understand what you mean by "scroll is not set to line
> 0".  Please explain in more detail what you expected to happen (and
> why), and what did happen.

Expected is as per docstring:

    With a numeric prefix argument ARG, recenter putting point on screen line ARG
    relative to the selected window.

So, I expect that (recenter 0 t) will put the line at point on top of
the window and that (recenter 1 t) will put the line at point at the
second top line.

My expectation is met when I simply do emacs -Q M-: (recenter 0 t) or
emacs -Q M-: (recenter 1 t) on master.

Observed:

1. Line at point slowly scrolls up until it reaches top of the window
(`pixel-scroll-precision-interpolate' call)

2. Line at point is reset back to its initial scroll position
   (`recenter' call)

Sometimes, I also observe line at point moving beyond the screen.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 70386@debbugs.gnu.org
> Date: Sun, 14 Apr 2024 19:36:04 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1. emacs -Q
> >> 2. Insert the following into scratch buffer and put point at "recenter"
> >
> > Which "recenter": the one in the comment or the one in (recenter 0 t) ?
> 
> The "(recenter 0 t))" line.
> 
> >> (progn
> >>   (require 'pixel-scroll)
> >>   (pixel-scroll-precision-interpolate
> >>    (* -1 (line-pixel-height)
> >>       (max 0 (- (count-screen-lines (window-start) (point)) 2)))
> >>    nil 1)
> >>   ;; Call original recenter for final adjustment.
> >>   (recenter 0 t))
> >> 
> >> 3. M-x eval-buffer
> >> 4. Observe that scroll is not set to line 0, despite calling `recenter'
> >
> > I don't think I understand what you mean by "scroll is not set to line
> > 0".  Please explain in more detail what you expected to happen (and
> > why), and what did happen.
> 
> Expected is as per docstring:
> 
>     With a numeric prefix argument ARG, recenter putting point on screen line ARG
>     relative to the selected window.
> 
> So, I expect that (recenter 0 t) will put the line at point on top of
> the window and that (recenter 1 t) will put the line at point at the
> second top line.
> 
> My expectation is met when I simply do emacs -Q M-: (recenter 0 t) or
> emacs -Q M-: (recenter 1 t) on master.
> 
> Observed:
> 
> 1. Line at point slowly scrolls up until it reaches top of the window
> (`pixel-scroll-precision-interpolate' call)
> 
> 2. Line at point is reset back to its initial scroll position
>    (`recenter' call)

What is the "initial scroll position" in this case?

> Sometimes, I also observe line at point moving beyond the screen.

It's inconsistent in my testing: sometimes works as I'd expect, and
sometimes ends up with window's vscroll that is very small: about 1
screen line.

Po Lu, could you please look into this?  Something in
pixel-scroll-precision-interpolate is randomly misbehaving, at least
on my system.  Since all of this stuff is extremely fragile, it's
possible that one of the recent changes in xdisp.c broke it somehow.
But the behavior is not consistent, so I wonder what could cause that.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Observed:
>> 
>> 1. Line at point slowly scrolls up until it reaches top of the window
>> (`pixel-scroll-precision-interpolate' call)
>> 
>> 2. Line at point is reset back to its initial scroll position
>>    (`recenter' call)
>
> What is the "initial scroll position" in this case?

The position before M-x eval-buffer

In other words, the window slowly scrolls up, moving the point to the
top, but then quickly resets back to how it looked like before the
scroll started.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Po Lu <luangruo@yahoo.com>, 70386@debbugs.gnu.org
> Date: Mon, 15 Apr 2024 17:13:39 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Observed:
> >> 
> >> 1. Line at point slowly scrolls up until it reaches top of the window
> >> (`pixel-scroll-precision-interpolate' call)
> >> 
> >> 2. Line at point is reset back to its initial scroll position
> >>    (`recenter' call)
> >
> > What is the "initial scroll position" in this case?
> 
> The position before M-x eval-buffer
> 
> In other words, the window slowly scrolls up, moving the point to the
> top, but then quickly resets back to how it looked like before the
> scroll started.

No, it does not, at least not on my system.  There's a small vscroll
(you should see it if you move the cursor vertically with C-p after
eval-buffer returns).  So the code works, it just yields a vscroll
that is not what you expect for some reason (and in about 50% of my
attempts -- in the rest the code works as you expect).

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Mon, 15 Apr 2024 18:45:48 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> In other words, the window slowly scrolls up, moving the point to the
> >> top, but then quickly resets back to how it looked like before the
> >> scroll started.
> >
> > No, it does not, at least not on my system.  There's a small vscroll
> > (you should see it if you move the cursor vertically with C-p after
> > eval-buffer returns).  So the code works, it just yields a vscroll
> > that is not what you expect for some reason (and in about 50% of my
> > attempts -- in the rest the code works as you expect).
> 
> See the attached screencast on what I am seeing.

If you look closely, you will see that even in that screencast the
starting and the ending display are not identical: there's a small
vertical displacement in the latter wrt the former.

Besides, the start of the screencast is not immediately after entering
"emacs -Q".  I think you started recording after several attempts, and
didn't restore the initial position after each attempt.  I know this
because the first line of *scratch* is barely visible when you begin
the screencast.

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

[Eli Zaretskii]

Ping!  Po Lu, could you please look into this issue?

> Cc: 70386@debbugs.gnu.org
> Date: Mon, 15 Apr 2024 19:11:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Ihor Radchenko <yantar92@posteo.net>
> > Cc: 70386@debbugs.gnu.org
> > Date: Sun, 14 Apr 2024 19:36:04 +0000
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> 1. emacs -Q
> > >> 2. Insert the following into scratch buffer and put point at "recenter"
> > >
> > > Which "recenter": the one in the comment or the one in (recenter 0 t) ?
> > 
> > The "(recenter 0 t))" line.
> > 
> > >> (progn
> > >>   (require 'pixel-scroll)
> > >>   (pixel-scroll-precision-interpolate
> > >>    (* -1 (line-pixel-height)
> > >>       (max 0 (- (count-screen-lines (window-start) (point)) 2)))
> > >>    nil 1)
> > >>   ;; Call original recenter for final adjustment.
> > >>   (recenter 0 t))
> > >> 
> > >> 3. M-x eval-buffer
> > >> 4. Observe that scroll is not set to line 0, despite calling `recenter'
> > >
> > > I don't think I understand what you mean by "scroll is not set to line
> > > 0".  Please explain in more detail what you expected to happen (and
> > > why), and what did happen.
> > 
> > Expected is as per docstring:
> > 
> >     With a numeric prefix argument ARG, recenter putting point on screen line ARG
> >     relative to the selected window.
> > 
> > So, I expect that (recenter 0 t) will put the line at point on top of
> > the window and that (recenter 1 t) will put the line at point at the
> > second top line.
> > 
> > My expectation is met when I simply do emacs -Q M-: (recenter 0 t) or
> > emacs -Q M-: (recenter 1 t) on master.
> > 
> > Observed:
> > 
> > 1. Line at point slowly scrolls up until it reaches top of the window
> > (`pixel-scroll-precision-interpolate' call)
> > 
> > 2. Line at point is reset back to its initial scroll position
> >    (`recenter' call)
> 
> What is the "initial scroll position" in this case?
> 
> > Sometimes, I also observe line at point moving beyond the screen.
> 
> It's inconsistent in my testing: sometimes works as I'd expect, and
> sometimes ends up with window's vscroll that is very small: about 1
> screen line.
> 
> Po Lu, could you please look into this?  Something in
> pixel-scroll-precision-interpolate is randomly misbehaving, at least
> on my system.  Since all of this stuff is extremely fragile, it's
> possible that one of the recent changes in xdisp.c broke it somehow.
> But the behavior is not consistent, so I wonder what could cause that.
> 
> 
> 
> 

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!  Po Lu, could you please look into this issue?

I will, thanks.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Ping!  Po Lu, could you please look into this issue?
>
> I will, thanks.

Should be fixed now, please test and ack.

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

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> Ping!  Po Lu, could you please look into this issue?
>>
>> I will, thanks.
>
> Should be fixed now, please test and ack.

I just tried the latest master (make bootstrap).
I am still able to reproduce the original steps, although not every time
I run M-x eval-buffer.

(progn
  (require 'pixel-scroll)
  (pixel-scroll-precision-interpolate
   (* -1 (line-pixel-height)
      (max 0 (- (count-screen-lines (window-start) (point)) 2)))

^^^ changing 2 to 3,4,5 or resizing frame changes the scrolling
behavior. Sometimes, the recentering does leave the point on top, but
the point moves down a few lines. Sometimes, recentering does not happen
as in the original report. Sometimes, the recentering works.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

Ping!  Po Lu, can you please take another look?

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 70386@debbugs.gnu.org
> Date: Mon, 29 Apr 2024 18:31:19 +0000
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Po Lu <luangruo@yahoo.com> writes:
> >
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >>> Ping!  Po Lu, could you please look into this issue?
> >>
> >> I will, thanks.
> >
> > Should be fixed now, please test and ack.
> 
> I just tried the latest master (make bootstrap).
> I am still able to reproduce the original steps, although not every time
> I run M-x eval-buffer.
> 
> (progn
>   (require 'pixel-scroll)
>   (pixel-scroll-precision-interpolate
>    (* -1 (line-pixel-height)
>       (max 0 (- (count-screen-lines (window-start) (point)) 2)))
> 
> ^^^ changing 2 to 3,4,5 or resizing frame changes the scrolling
> behavior. Sometimes, the recentering does leave the point on top, but
> the point moves down a few lines. Sometimes, recentering does not happen
> as in the original report. Sometimes, the recentering works.
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
> 

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!  Po Lu, can you please take another look?

I tried might and main to reproduce the vscroll-related problem
following both the original recipe and the adjustments Ihor suggested,
to no avail.

Ihor, are you still running recenter?  The bug you initially described
should not be possible after my change, as vscroll is now
unconditionally reset after a call to recenter, but the paragraph in
your last message appears to describe a different phenomenon, which is
no bug: since p-s-p-i is designed for interactive operation, the
animation runs within `while-no-input', and if input should interrupt
the usual course of the function, then it's entirely expected that point
should be left elsewhere than specified in the arguments of the call.

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

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> I tried might and main to reproduce the vscroll-related problem
> following both the original recipe and the adjustments Ihor suggested,
> to no avail.
>
> Ihor, are you still running recenter?  The bug you initially described
> should not be possible after my change, as vscroll is now
> unconditionally reset after a call to recenter, but the paragraph in
> your last message appears to describe a different phenomenon, which is
> no bug: since p-s-p-i is designed for interactive operation, the
> animation runs within `while-no-input', and if input should interrupt
> the usual course of the function, then it's entirely expected that point
> should be left elsewhere than specified in the arguments of the call.

See my recording of emacs -Q:
https://0x0.st/XKzU.mp4

My Emacs is built a few days ago from master:
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-05-08 built on localhost
Repository revision: 1fb335251330108b70042afd45def623535e274e
Repository branch: master

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 70386@debbugs.gnu.org
> Date: Sat, 11 May 2024 17:48:24 +0000
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > I tried might and main to reproduce the vscroll-related problem
> > following both the original recipe and the adjustments Ihor suggested,
> > to no avail.
> >
> > Ihor, are you still running recenter?  The bug you initially described
> > should not be possible after my change, as vscroll is now
> > unconditionally reset after a call to recenter, but the paragraph in
> > your last message appears to describe a different phenomenon, which is
> > no bug: since p-s-p-i is designed for interactive operation, the
> > animation runs within `while-no-input', and if input should interrupt
> > the usual course of the function, then it's entirely expected that point
> > should be left elsewhere than specified in the arguments of the call.
> 
> See my recording of emacs -Q:
> https://0x0.st/XKzU.mp4

Does that really answer the questions above?

Btw, the "input" which interrupts while-no-input might come from
sources you might not expect.

All in all, I don't understand what is this bug about, for quite some
time.  I fail to see anything here that is worth keeping to dig into
this.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> See my recording of emacs -Q:
>> https://0x0.st/XKzU.mp4
>
> Does that really answer the questions above?
>
> Btw, the "input" which interrupts while-no-input might come from
> sources you might not expect.
>
> All in all, I don't understand what is this bug about, for quite some
> time.  I fail to see anything here that is worth keeping to dig into
> this.

When I have

(progn
 ...
 (recenter 0 t))

I expect the final result to be just the same as

(recenter 0 t)

but it is not what I am seeing.

Is it more clear?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sat, 11 May 2024 18:00:25 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> See my recording of emacs -Q:
> >> https://0x0.st/XKzU.mp4
> >
> > Does that really answer the questions above?
> >
> > Btw, the "input" which interrupts while-no-input might come from
> > sources you might not expect.
> >
> > All in all, I don't understand what is this bug about, for quite some
> > time.  I fail to see anything here that is worth keeping to dig into
> > this.
> 
> When I have
> 
> (progn
>  ...
>  (recenter 0 t))
> 
> I expect the final result to be just the same as
> 
> (recenter 0 t)
> 
> but it is not what I am seeing.
> 
> Is it more clear?

The result can legitimately depend on what is inside progn, because
what's there could affect point, and that in turn affects which line
recenter puts on the first window line, or even if it can do that.

So in this general form, the expectation is not correct.  Perhaps if
you made it less general and more specific to what the code inside
progn actually does, we could discuss this in a more useful manner.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> The result can legitimately depend on what is inside progn, because
> what's there could affect point, and that in turn affects which line
> recenter puts on the first window line, or even if it can do that.

In my specific reproducer the point is not moved, AFAIK.

> So in this general form, the expectation is not correct.  Perhaps if
> you made it less general and more specific to what the code inside
> progn actually does, we could discuss this in a more useful manner.

The code inside progn (1) invokes approximate smooth scrolling (2)
forces the scrolling to move to the final location accurately.

The reproducer is adopted from my custom function that makes recentering
use smooth scrolling. The code started to act unpredictably from time to
time with point ending outside window boundaries after one of recent-ish
pulls from master.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sat, 11 May 2024 18:42:10 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The result can legitimately depend on what is inside progn, because
> > what's there could affect point, and that in turn affects which line
> > recenter puts on the first window line, or even if it can do that.
> 
> In my specific reproducer the point is not moved, AFAIK.

Of course it can move: as the window is scrolled by
pixel-scroll-precision-interpolate, point can become invisible.  If
redisplay kicks in, it will move point to bring it back into the
viewport.

> > So in this general form, the expectation is not correct.  Perhaps if
> > you made it less general and more specific to what the code inside
> > progn actually does, we could discuss this in a more useful manner.
> 
> The code inside progn (1) invokes approximate smooth scrolling (2)
> forces the scrolling to move to the final location accurately.
> 
> The reproducer is adopted from my custom function that makes recentering
> use smooth scrolling. The code started to act unpredictably from time to
> time with point ending outside window boundaries after one of recent-ish
> pulls from master.

That the behavior changed recently doesn't yet mean the previous
behavior was correct and the new one is wrong.  It might mean your
code is based on incorrect assumptions, and just happened to work
previously by sheer luck.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> In my specific reproducer the point is not moved, AFAIK.
>
> Of course it can move: as the window is scrolled by
> pixel-scroll-precision-interpolate, point can become invisible.  If
> redisplay kicks in, it will move point to bring it back into the
> viewport.

But it is not what happens in the recording!
The point remains at the same line.
Or do you mean that the point is somehow moved around during the progn execution?
But it does not look like it is the case - when I try

(setq point-list nil)
(setq current-line-list nil)
(progn
  (push (point) point-list)
  (push (count-lines 1 (point)) current-line-list)
  (require 'pixel-scroll)
  (push (point) point-list)
  (push (count-lines 1 (point)) current-line-list)
  (pixel-scroll-precision-interpolate
   (* -1 (line-pixel-height)
      (max 0 (- (count-screen-lines (window-start) (point)) 2)))
   nil 1)
  (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

I still do not see "recenter putting point on screen line 0" (quote from
`recenter' docstring) after finishing progn and all the elements of
`point-list' are the same positions.

> ...
> That the behavior changed recently doesn't yet mean the previous
> behavior was correct and the new one is wrong.  It might mean your
> code is based on incorrect assumptions, and just happened to work
> previously by sheer luck.

Maybe. But I do believe that my reproducer demonstrates a bug.
I do not want to argue about my original code and want to focus on the
reproducer herein instead. I only mentioned this detail for some context.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sat, 11 May 2024 19:09:34 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> In my specific reproducer the point is not moved, AFAIK.
> >
> > Of course it can move: as the window is scrolled by
> > pixel-scroll-precision-interpolate, point can become invisible.  If
> > redisplay kicks in, it will move point to bring it back into the
> > viewport.
> 
> But it is not what happens in the recording!
> The point remains at the same line.

That's only what you see when redisplay shows you something.  That's
not all that happens.

> Or do you mean that the point is somehow moved around during the progn execution?

Of course, it does!  Even eval-buffer itself moves point.

> But it does not look like it is the case - when I try
> 
> (setq point-list nil)
> (setq current-line-list nil)
> (progn
>   (push (point) point-list)
>   (push (count-lines 1 (point)) current-line-list)
>   (require 'pixel-scroll)
>   (push (point) point-list)
>   (push (count-lines 1 (point)) current-line-list)
>   (pixel-scroll-precision-interpolate
>    (* -1 (line-pixel-height)
>       (max 0 (- (count-screen-lines (window-start) (point)) 2)))
>    nil 1)
>   (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.

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.

> > That the behavior changed recently doesn't yet mean the previous
> > behavior was correct and the new one is wrong.  It might mean your
> > code is based on incorrect assumptions, and just happened to work
> > previously by sheer luck.
> 
> Maybe. But I do believe that my reproducer demonstrates a bug.

Why do you still believe that?  What will it take to convince you that
in the situation your recipe creates the result can sometimes be not
what you want?

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

[Ihor Radchenko]

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.
Or do _previous_ point positions affect `recenter'?

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

    With a numeric prefix argument ARG, recenter putting point on screen line ARG
    relative to the selected window.  If ARG is negative, it counts up from the
    bottom of the window.  (ARG should be less than the height of the window.)

>> Maybe. But I do believe that my reproducer demonstrates a bug.
>
> Why do you still believe that?  What will it take to convince you that
> in the situation your recipe creates the result can sometimes be not
> what you want?

At least, a docstring that explains what `recenter' does better.
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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

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

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

I do not consider the case when scrolling "overshoots" the window
boundary and moves point as a bug. I only consider the other case, when
the point does not move as a bug.

Try the following - it should not overshoot and should be more deterministic:

(setq point-list nil)
(setq current-line-list nil)
(progn
  (push (point) point-list)
  (push (count-lines 1 (point)) current-line-list)
  (require 'pixel-scroll)
  (push (point) point-list)
  (push (count-lines 1 (point)) current-line-list)
  (pixel-scroll-precision-interpolate
   (* -1 (line-pixel-height)
      (max 0 (- (count-screen-lines (window-start) (point)) 4)))
   nil 1)
  (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))

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

That would at least make me aware that there are shaky grounds to worry
about.

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

By current line, I mean "line containing point". Again, I am not worried
about the case when scrolling changes point position and that new
position gets recentered. I am only worried about the case when the
rencentering does not alter the final window scroll, despite the point
not being on the requested visual line.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sun, 12 May 2024 06:58:32 +0000
> 
> Try the following - it should not overshoot and should be more deterministic:

It is still very much unpredictable: sometimes shows the last line at
the window's top, sometimes doesn't.

P.S. You didn't tell how to run this recipe; I used "M-x eval-buffer".

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
>> Date: Sun, 12 May 2024 06:58:32 +0000
>> 
>> Try the following - it should not overshoot and should be more deterministic:
> ...
> P.S. You didn't tell how to run this recipe; I used "M-x eval-buffer".

I also move point somewhere in the middle of progn before running M-x eval-buffer.

> It is still very much unpredictable: sometimes shows the last line at
> the window's top, sometimes doesn't.

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sun, 12 May 2024 07:17:29 +0000
> 
> > It is still very much unpredictable: sometimes shows the last line at
> > the window's top, sometimes doesn't.
> 
> 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.

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

[Ihor Radchenko]

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

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

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> It is still very much unpredictable: sometimes shows the last line at
> the window's top, sometimes doesn't.

Let's try a slightly different recipe:

1. emacs -Q
2. Insert
(progn
  (require 'pixel-scroll)
  (pixel-scroll-precision-interpolate
   (* -1 (line-pixel-height)) nil 1)
  (recenter 0 t))
3. Move point to "progn"
4. M-x eval-buffer

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sun, 12 May 2024 07:19:51 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is still very much unpredictable: sometimes shows the last line at
> > the window's top, sometimes doesn't.
> 
> Let's try a slightly different recipe:
> 
> 1. emacs -Q
> 2. Insert
> (progn
>   (require 'pixel-scroll)
>   (pixel-scroll-precision-interpolate
>    (* -1 (line-pixel-height)) nil 1)
>   (recenter 0 t))
> 3. Move point to "progn"
> 4. M-x eval-buffer

Still unpredictable.  Sometimes point ends up on progn with
window-start being 1 as at the beginning, sometimes I see the
"recenter" line at the top line with point at EOB (i.e. below that
line).

Why do you think some minor modifications of the recipe should affect
the results?

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1. emacs -Q
>> 2. Insert
>> (progn
>>   (require 'pixel-scroll)
>>   (pixel-scroll-precision-interpolate
>>    (* -1 (line-pixel-height)) nil 1)
>>   (recenter 0 t))
>> 3. Move point to "progn"
>> 4. M-x eval-buffer
>
> Still unpredictable.  Sometimes point ends up on progn with
> window-start being 1 as at the beginning, sometimes I see the
> "recenter" line at the top line with point at EOB (i.e. below that
> line).

Ok. I can see what might be going on here - M-x eval-buffer
moves the point before evaluation, causing this weird behavior.

If I convert my recipe to a defun, there is no problem.

I am still seeing weirdness on my side though with Emacs entering a
state when calling M-: (recenter -1 t) does nothing even when the buffer
should be scrolled (point not near the top of buffer). But I am unable
to get a reliable reproducer. Feel free to close this bug report.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> Date: Sun, 19 May 2024 13:49:02 +0000
> 
> If I convert my recipe to a defun, there is no problem.
> 
> I am still seeing weirdness on my side though with Emacs entering a
> state when calling M-: (recenter -1 t) does nothing even when the buffer
> should be scrolled (point not near the top of buffer). But I am unable
> to get a reliable reproducer. Feel free to close this bug report.

If Po Lu thinks this issue is resolved, we can indeed close it.

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

[Eli Zaretskii]

> Cc: 70386@debbugs.gnu.org
> Date: Sun, 19 May 2024 18:29:03 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Ihor Radchenko <yantar92@posteo.net>
> > Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
> > Date: Sun, 19 May 2024 13:49:02 +0000
> > 
> > If I convert my recipe to a defun, there is no problem.
> > 
> > I am still seeing weirdness on my side though with Emacs entering a
> > state when calling M-: (recenter -1 t) does nothing even when the buffer
> > should be scrolled (point not near the top of buffer). But I am unable
> > to get a reliable reproducer. Feel free to close this bug report.
> 
> If Po Lu thinks this issue is resolved, we can indeed close it.

Ping!

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 70386@debbugs.gnu.org
>> Date: Sun, 19 May 2024 18:29:03 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > From: Ihor Radchenko <yantar92@posteo.net>
>> > Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org
>> > Date: Sun, 19 May 2024 13:49:02 +0000
>> > 
>> > If I convert my recipe to a defun, there is no problem.
>> > 
>> > I am still seeing weirdness on my side though with Emacs entering a
>> > state when calling M-: (recenter -1 t) does nothing even when the buffer
>> > should be scrolled (point not near the top of buffer). But I am unable
>> > to get a reliable reproducer. Feel free to close this bug report.
>> 
>> If Po Lu thinks this issue is resolved, we can indeed close it.
>
> Ping!

Yes, I agree that this is very much resolved.  Closing.