bug#61667: 29.0.60; Failure to redisplay

[Dmitry Gutov <dgutov@yandex.ru>]

On 21/02/2023 18:05, Eli Zaretskii wrote:
>> Date: Tue, 21 Feb 2023 17:51:01 +0200
>> Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org
>> From: Dmitry Gutov <dgutov@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.