bug#61667: 29.0.60; Failure to redisplay

[Dmitry Gutov]

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 <stefan@marxist.se>
> > 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.