GNU bug report logs - #70386
30.0.50; (recenter 0 t) does not put point on top of the window

Previous Next

Full log

Message #77 received at 70386 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 70386 <at> debbugs.gnu.org
Subject: Re: bug#70386: 30.0.50; (recenter 0 t) does not put point on top of
 the window
Date: Sun, 12 May 2024 06:58:32 +0000

Eli Zaretskii <eliz <at> 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>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.