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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: bug#61667: 29.0.60; Failure to redisplay
Date: Thu, 23 Feb 2023 21:12:42 +0200

On 23/02/2023 19:10, Eli Zaretskii wrote:
>> Here's one repro:
>>
>> emacs -Q --eval "(tool-bar-mode -1)" --eval "(menu-bar-mode -1)" --eval
>> "(scroll-bar-mode -1)" --eval "(global-set-key \"a\" (lambda ()
>> (interactive) (find-file \"test.c\")))"
>>
>> Where "test.c" is the name of a file in the current dir. Different files
>> can work, but for some the repro doesn't happen, like those, apparently,
>> which start with a paren (which makes show-paren-mode trigger its own
>> redisplay).
>>
>> So, to repro:
>>
>> - Run the command above
>> - Press "a"
>> - Look for the delay between the title bar and the window updates
>>
>> With the above 'emacs -Q' it's not as prominent as with my config, but
>> it can reach what looks like 100-200ms. Once every 10 tries or so.
> Isn't that the 100-ms delay we wait for the initial frame to finish
> displaying, since that requires that we receive some messages from X?

Probably not: in this scenario I usually wait for the frame to finish 
resizing, rendering, etc, and for *scratch* to be displayed properly, 
and then I press 'a'.

But I might have misunderstood your question.

> So I'm not sure this is the same problem.  Unless, that is, in the
> "problematic" cases we somehow miss the message which we are waiting
> for?

It might be related if there are similar timeouts for subsequent 
redisplay operations.

Previous Next

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