Subject: bug#61667: 29.0.60; Failure to redisplay

From: Dmitry Gutov <[email-masked]>
Date: Tue, 21 Feb 2023 22:53:13 +0200

On 21/02/2023 20:31, Eli Zaretskii wrote:
>> Date: Tue, 21 Feb 2023 19:25:28 +0200
>> Cc: [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>>> 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).
> 
> So you:
> 
>    . start Emacs
>    . wait for the initial frame to be redrawn after the init files are
>      processed
>    . visit a file by typing "C-x b" and selecting a file from a list
> 
> And then you see an empty window with the frame's title showing the
> file you selected.  Is that correct?

Not exactly empty, just not updated. I guess I was saying it's blank 
because the scratch is usually displayed as blank. But I wasn't able to 
repro this with non-empty scratch. Not in the latest experiments, at least.

> If so, what do you see on the
> mode line as the buffer name?

Whatever it was showing before I hit RET. Its contents for *scratch*, I 
guess.

>> Overall, though, the unoptimized build makes it harder to reproduce:
>> I've only managed that 3 times, so far.
> 
> Which likely means this is some kind of timing issue.  Which perhaps
> also explains why trace-redisplay stops it from happening: it slows
> down redisplay because it needs to output the traces.  So we are
> looking at some X or GTK event that comes in and somehow interrupts or
> prevents redisplay from doing its job, after it evidently started
> (because the frame title is updated at the beginning of a redisplay
> cycle)?  Or maybe it's something that prevents us from swapping the
> double-buffering buffers so that the redrawn stuff is actually shown
> on the glass?

I understand you are musing here.

>> 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.
> 
> The echo area is shown in a window, so that seems to be part of not
> updating the windows on display.

Yep. Or to be more precise, the whole frame contents are not updated. 
Just the title. At first.