GNU bug report logs - #61667
29.0.60; Failure to redisplay

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org
Subject: Re: bug#61667: 29.0.60; Failure to redisplay
Date: Tue, 21 Feb 2023 19:25:28 +0200

On 21/02/2023 18:05, Eli Zaretskii wrote:
>> Date: Tue, 21 Feb 2023 17:51:01 +0200
>> Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> 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.
> 
> I'm not surer I follow: why should a frame resize in this case?  You
> just visit a file in an existing window of an existing frame, right?
> Or is the situation more complicated?  If the latter, please tell the
> details, they could be relevant.

Given how slow the unoptimized build is, I can usually start (and 
finish) typing the command before Emacs has fully finished processing 
the init script, including the default face customizations (which result 
in frame resizing).

>> 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.
> 
> Not following again: wait for what?  And what happens when you use
> "C-x b"?

'C-x b' followed by the file name from history, followed by RET -> 
visiting the previously visited file. From recentf.

This behavior is driven by the option ido-virtual-buffers. Unlikely 
affects something.

But it allows me to shorten the scenario of visiting a file for the 
first time after launching Emacs, so that I can trigger the bug faster 
(over several tries).

Overall, though, the unoptimized build makes it harder to reproduce: 
I've only managed that 3 times, so far.

Reproducing it by killing a buffer and then re-visiting in the same 
session seems harder still, but I've just managed to do it once.

>> 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.
> 
> Which seems to mean that redisplay was called (and produced the
> updated frame title), but for some reason decided that none of the
> windows need redrawing.

Apparently so.

> Or (given your report about double-buffering)
> didn't reflect the new content on display?

Can't tell which one it is.

But the echo area is not getting redrawn either: the selection of 
buffers to switch to is still visible as it was when I pressed RET. Just 
the title bar changes. The echo area is updated together with the main 
window showing the buffer.

Previous Next

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