GNU bug report logs - #76186
31.0.50; (recenter 0) sometimes does not recenter as expected

Previous Next

Full log

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Thu, 13 Feb 2025 19:51:35 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> What is special or noteworthy about the cases where it doesn't work as
> expected?

Here is what I found out so far regarding this key question:

Considering a few key indicators, major preconditions of the cases where
it works as expected are exactly identical to the cases where it doesn't
work as expected:

    0. the frame and window geometry are the same and not atypical,
       the font is the same and the characters are only ASCII,
       lines are not overly long and not truncated, no text properties
       or overlays are used in the example I posted
    1. the buffer contents are the same in all cases
    2. point is always at (point-max) when (recenter 0) is invoked
    3. redispay is always called so that recentering can take effect.

Yet, there is something that distinguishes the cases, because in some
cases the recentering works as expected, and in other (rare) cases it
doesn't work as expected even though points (0) to (3) are all the same.
For instance, the loop I posted keeps all these factors the same in each
iteration, yet throws an exception in some but not all iterations.

At one time I believed that undo-auto-current-boundary-timer, which runs
every 10 seconds, may play a role. However, the issue also arises on
both systems I tested even after I cancel the timer.

At another time, I believed that fontification plays a role, but I
eventually found that the issue also arises with font-lock-mode disabled,
and the example I posted does not use font-lock-mode.

I cannot elicit the issue if I remove the creation, modification and
deletion of the frame denoted by `frame' in the snippet I posted. This
could be an indication that the interaction of frames may play a role,
in such a way that some iterations behave differently than others even
though the factors mentioned above are exactly the same in all cases.

Thank you and all the best,
Markus

Previous Next

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