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

Previous Next

Full log

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Mon, 17 Mar 2025 13:19:33 +0100

On Sun, 16 Mar 2025 17:47:01 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
>> Date: Sun, 16 Mar 2025 17:20:51 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> > From: Stephen Berman <stephen.berman <at> gmx.net>
>> > Cc: Markus Triska <triska <at> metalevel.at>,  76186 <at> debbugs.gnu.org
>> > Date: Sun, 16 Mar 2025 14:20:33 +0100
>> >
>> > Although you already said upthread you could not reproduce the issue
>> > with the test code I posted, I'd ask you to try again with the attached
>> > file, i.e. from the shell:
>> >
>> > emacs -Q -l bug#76186.el
>> >
>> > This file differs from the one I posted upthread only in that the first
>> > occurrence of `(redisplay)' is commented out, so possibly you overlooked
>> > that when you tested previously (my explanation of my testing was a bit
>> > terse).  With that difference I consistently get the unexpected
>> > recentering after a single iteration.  What's more, I've now also
>> > reproduced this with emacs-30 running under MS-Windows 10 in a virtual
>> > machine (I used emacs-30.1-installer.exe downloaded from a GNU mirror).
>> > Perhaps I missed something when debugging this, so if you can also
>> > reproduce it, you might be able to debug it better than I did.
>>
>> Will do, thanks.
>
> Sigh...  I will look into this when I have time, but from what I've
> seen until now, this reproducer is unfortunately not very interesting.
> The reason is that it only reproduces the problem if I invoke it
> exactly as you show:
>
>   emacs -Q -l bug#76186.el
>
> But if I start "emacs -Q" and then manually load-file bug#76186.el
> into the running Emacs, the problem doesn't happen here.  Moreover, if
> I make the following small modification of your code, by adding these
> 3 lines:
>
>   (blink-cursor-mode -1)
>   (global-eldoc-mode -1)
>   (sit-for 0.1)
>
> just before the call to sometimes-not-recentering, and invoke Emacs
> exactly as above, the problem also disappears.  So it looks like at
> least one of the reasons in the case that reproduces immediately is
> that Emacs starts running the function with the initial GUI frame not
> yet finalized (it takes time for the GUI system to initialize and show
> a window on the desktop), which is a huge turn-off for me, because
> basically we are working with an insufficiently finalized display
> arrangement (e.g., who knows what are the frame dimensions known to
> the display code at that point?), and that is very uninteresting.

I can reproduce your obvervations on MS-Windows 10 in the virtual
machine.  But on GNU/Linux even with the blink-cursor-mode,
global-eldoc-mode and sit-for calls added I still get the unexpected
recentering after a single iteration; and when I invoke emacs -Q and
then load bug#76186.el, I still get the unexpected recentering, not
immediately after one iteration but after only a few, mostly two or
three, and then after only a few test runs (often already the second
one), the unexpected recentering also occurs after a single iteration
(this is both with and without adding the above three invocations to the
test file).  Is there a difference between how MS-Windows and GNU/Linux
create the initial GUI frame that could account for these observations?

> Still, I will try to step through the code when I have time, although
> it's unlikely to uncover more than I already said in this thread.

Thanks, I look forward to your findings.

Steve Berman

Previous Next

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