Subject: Re: bug#61667: 29.0.60; Failure to redisplay

From: Dmitry Gutov <[email-masked]>
Date: Fri, 24 Feb 2023 15:46:15 +0200

On 24/02/2023 15:20, Gregory Heytings wrote:
>>
>> So, I finished bisecting, at it points to:
>>
>> 817dd546497aadefbe9acc8762e3f7190799c5e6 is the first bad commit
>> commit 817dd546497aadefbe9acc8762e3f7190799c5e6
>> Author: Stefan Kangas <[email-masked]>
>> Date:   Sun Sep 13 18:24:31 2020 +0200
>>
>>    Improve frame-title-format and icon-title-format
>>
>>    * src/xdisp.c (syms_of_xdisp): Replace 'invocation-name' with the text
>>    "%b - GNU Emacs" and replace "@" with " at ".  (Bug#41147)
>>    * etc/NEWS: Announce the above change.
>>
> 
> Aha.  This is rather surprising, but it also means that GNOME has 
> perhaps nothing to do with the bug.  As I said in my other post, can you 
> possibly try to reproduce the bug with your config with a non-GNOME 
> window manager? (I don't know what distro you use, but there are a 
> number of very lightweight window managers that you can easily install 
> and remove.)

I don't have any of them installed, but I can try. Which one do you 
recommend? Perhaps we should choose one that still uses GTK3?

I use stock Ubuntu (22.10).

>> - Before this commit: the window title doesn't change, it's always 
>> emacs@hostname. But when I press 'a' (bound to 'find-file' lambda), 
>> there never is a noticeable delay before the window contents change. 
>> The buffer is displayed instantly.
>>
> 
> This means that if you set frame-title-format to some constant string in 
> Emacs 29 the bug should also disappear.  Can you check that?

Hmm, yes.

   --eval "(setq frame-title-format \"foo bar foo\")"

indeed makes the problem go away. Both the 200-300ms delay in my repro 
scenario, and the multi-second delay with my personal configuration.