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

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected
Date: Wed, 12 Feb 2025 22:53:52 +0100

On Wed, 12 Feb 2025 22:09:50 +0100 Markus Triska <triska <at> metalevel.at> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> They still don't reproduce the problem for me.  And I cannot really
>> try playing with the various settings that might affect this because
>> the recipe runs in a loop, all the time changing the frame being
>> tested.
>>
>> Like I said: it will be much easier if you provide just one
>> configuration for the frame in which you see the problem, because then
>> I could try changing the font and the dimensions until I succeed in
>> triggering.
>
> The issue the snippet is intended to demonstrate is that recentering
> does not work in rare cases, even when used with the exact same settings
> as in those cases where it works. This is the reason why a loop is
> involved that repeats the exact steps over and over, in order to attempt
> to elicit the rare case in which the exact same steps unexpectedly yield
> a different result than in all other cases where they are executed.
>
> If I find a test case where recentering always yields an unexpected
> result, I will add it immediately to this issue.
>
>> Or maybe you could just post the real-life scenario where this
>> happened to you.  Or did that also happen when you invoke recenter in
>> a loop?
>
> Yes of course: The real-life scenario where I noticed this problem is a
> situation where I use (recenter 0) in an Elisp application, with the
> expectation that it - as documented - recenters point at the topmost
> line of the window. The application works well, and recentering
> generally works as expected. However, I noticed that sometimes (rarely),
> it does not work, even in situations where at other times it works as
> expected. The snippet I posted is an attempt to distill the essence of
> the issue, by retaining only those instructions that suffice to exhibit
> the issue on both of the two systems I tested it with so far (OSX and
> Debian).
>
>> People who can reproduce this are welcome to debug the problem and
>> describe what they saw.
>
> Yes, thank you a lot, it would already help me greatly to know that
> someone can also see the issue with the example I posted.  I will also
> try to find a way to make it more reproducible, also by testing it on
> other systems I have access to.

I can reproduce the issue, both with the original code snippet and the
current one, on this system:

GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.2) of 2025-02-06 built on strobelfssd
Repository revision: ea04dd8ca93d609c0ee475c4acf58a56dfc0f1f3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Linux From Scratch r12.2-17-systemd

Configured using:
 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig'

I haven't tried to debug it and don't really have a good idea how to
proceed with that, but I'll be happy to try any suggestions.  However, I
will be traveling for about a week and won't be able to do that till the
end of next week at the earliest.

Steve Berman

Previous Next

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