GNU bug report logs - #61667
29.0.60; Failure to redisplay

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Tue, 21 Feb 2023 02:55:01 UTC

Severity: normal

Found in version 29.0.60

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: bug#61667: 29.0.60; Failure to redisplay
Date: Fri, 24 Feb 2023 17:08:11 +0200
> Date: Fri, 24 Feb 2023 16:12:30 +0200
> Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> >> - 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.
> > How is this consistent with your previous finding that the problem
> > exists in Emacs 25, 26, and 27.  The change above is only present in
> > Emacs 28.  Does this mean that the problem 100-200ms delay and the
> > original problem are two different problems?
> 
> Easy: my configuration contains a customization for frame-title-format.
> 
> It's set to
> 
>    (setq frame-title-format '(buffer-file-name "%f" ("%b")))
> 
> All the time I spend bisecting the config I didn't think to change it 
> (it's the very first line). And this makes the problem appear with Emacs 
> 27 and 26 too.

So the hypothesis now is that changes in the frame's title, which
cause Emacs to update the title by issuing GTK and/or X calls, somehow
cause the problem, is that right?

> > Anyway, if the changes in the frame's title are somehow related to
> > this, their effect is to cause Emacs to call x_set_name_internal to
> > display the new title.  Could it be that this function takes such a
> > long time to execute?  Or does it have some strange effect on the WM?
> 
> My vague (and likely wrong) guess would be that the WM knows it needs 
> some update from the Emacs window, gets it from the title bar before 
> everything else, and marks the update as completed.

Can you please time that function anyway, if only to make sure the
problem is elsewhere?  How much time does it take x_set_name_internal
since its call till it returns, when it actually changes the frame's
title?




This bug report was last modified 1 year and 63 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.