|
From: | Dmitry Gutov |
Subject: | bug#61667: 29.0.60; Failure to redisplay |
Date: | Fri, 24 Feb 2023 15:46:15 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |