Subject: bug#61667: 29.0.60; Failure to redisplay

From: Dmitry Gutov <[email-masked]>
Date: Wed, 1 Mar 2023 16:33:11 +0200

On 01/03/2023 14:41, Po Lu via Bug reports for GNU Emacs, the Swiss army 
knife of text editors wrote:
> Dmitry Gutov<[email-masked]>  writes:
> 
>> Nope, it's for the "no problem" case. Hence the name.
> Huh, that's really weird.  If blink-cursor-mode is not the source of the
> inconsistencies, then the only explanation is that GNOME somehow behaves
> badly if:
> 
>    - the back buffer is displayed prior to the title being set.
>    - the WM name is changed.
>    - another buffer swap happens 400 ms later.

This delay happens because of the human factor: I need to hit 'a' after 
the frame has fully rendered, to run the command (which inserts !, 
redisplays, then calls find-file).

> I will try to see if I can reproduce this.
> 
>> I am sure, but just to verify, I redid the experiment again. See
>> attached files, the naming scheme is the same: two problem cases and
>> one "okay" case.
> Was blink-cursor-mode turned off, BTW?  If it is on, then potentially
> superfluous buffer swaps will end up in the logs once per
> blink-cursor-interval and screw them up.

But blink-cursor-mode was on, of course. It's -Q: everything's on what 
was not turned off.

And it turns out to be the reason for the difference between this and my 
personal config. With blink-cursor-mode off, the delay can reach 
multiple seconds like I previously reported.

Attaching new recordings with b-c-m off, same naming scheme.