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

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> posteo.net>

Date: Sun, 14 Apr 2024 16:34:02 UTC

Severity: normal

Found in version 30.0.50

Done: Po Lu <luangruo <at> yahoo.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: luangruo <at> yahoo.com, 70386 <at> debbugs.gnu.org
Subject: bug#70386: 30.0.50; (recenter 0 t) does not put point on top of the window
Date: Sun, 12 May 2024 09:00:42 +0300
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: luangruo <at> yahoo.com, 70386 <at> debbugs.gnu.org
> Date: Sat, 11 May 2024 19:09:34 +0000
> 
> Eli Zaretskii <eliz <at> 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?




This bug report was last modified 363 days ago.

Previous Next


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