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


Message #587 received at 61667 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61667 <at> debbugs.gnu.org
Subject: Re: bug#61667: 29.0.60; Failure to redisplay
Date: Sun, 16 Jun 2024 05:34:10 +0300
On 15/06/2024 09:49, Eli Zaretskii wrote:

>> Could this be a normal behavior? That is, having a delay between the
>> frame title changing and the insides of the frame updating.
> 
> Don't we invoke the backend's 'diff' method asynchronously in the
> above scenario?  Looking at vc-diff-internal, it looks like we first
> switch to the *vc-diff* buffer (which causes the frame's title to
> change, if redisplay happens to kick in, and only later show the
> actual diffs, when the async subprocess finishes.  Right?

Thanks, you're right.

It's not the async process itself, though (which is synchronous in 
vc-git-diff, see the comment with link to bug#21969), it's the font-lock 
application after.

Wrapping font-lock-fontify-keywords-region in benchmark-progn shows that 
call can take up hundreds of ms here, up to 1s. Not every time, but 
usually whenever a new commit referencing some large files (like 
xdisp.c) is displayed for the first time. As I recall there was another 
bug report about it, so I'll stop here.

Anyway, not a general redisplay problem, sorry for the false alarm.




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.