GNU bug report logs -
#61667
29.0.60; Failure to redisplay
Previous Next
Full log
Message #173 received at 61667 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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 <at> 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.
This bug report was last modified 1 year and 62 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.