GNU bug report logs -
#70386
30.0.50; (recenter 0 t) does not put point on top of the window
Previous Next
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: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: luangruo <at> yahoo.com, 70386 <at> debbugs.gnu.org
> Date: Sun, 12 May 2024 09:23:17 +0000
>
> Eli Zaretskii <eliz <at> 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?
This bug report was last modified 362 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.