bug#61667: 29.0.60; Failure to redisplay

[Dmitry Gutov]

On 21/02/2023 20:31, Eli Zaretskii wrote:
> > Date: Tue, 21 Feb 2023 19:25:28 +0200
> > Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > 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.