GNU bug report logs -
#61667
29.0.60; Failure to redisplay
Previous Next
Full log
Message #32 received at 61667 <at> debbugs.gnu.org (full text, mbox):
On 21/02/2023 14:58, Eli Zaretskii wrote:
>> Cc:61667 <at> debbugs.gnu.org
>> Date: Tue, 21 Feb 2023 12:43:29 +0200
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> With --eval '(trace-redisplay t)', redisplay always happens. ;-(
> That's strange: trace-redisplay just adds calls to functions that
> write to stderr, but doesn't change the display code in any way that
> could affect the control or data flow. So, unless this is some weird
> compiler bug, I don't understand how trace-redisplay could have
> affected this. Although the fact that with a tool bar displayed you
> cannot reproduce the problem is already weird for the same reason.
>
> If you build with no optimizations (CFLAGS=-O0 ./configure...), but
> without --enable-checking=glyphs, does the problem still happen?
Still reproduces, yes. As long as I don't hurry too much to type 'C-x b
file-name RET' too early, before the frame has managed to resize and
redisplay fully the first time.
So if I wait for it, and then use 'C-x b' (with Ido's support for
recentf), then I also can trigger the problem.
Oh, here's another description of the bug: the frame's title bar changes
(to display the visited file name), but the buffer is blank for a little
while.
>> That's not the effect of 'checking', though -- I can still repro if I
>> don't turn on redisplay tracing (which prints stuff in the background
>> window; maybe it's relevant, maybe it's not).
> By "background window" you mean a shell window from which you started
> Emacs? Or do you mean something else?
Yes, that one.
This bug report was last modified 1 year and 66 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.