GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, stephen.berman <at> gmx.net, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 10 Aug 2022 15:28:40 +0300
On 10.08.2022 15:04, Eli Zaretskii wrote:
>> Date: Wed, 10 Aug 2022 14:54:51 +0300
>> Cc:56682 <at> debbugs.gnu.org, Eli Zaretskii<eliz <at> gnu.org>,
>>   monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> On 10.08.2022 13:55, Stephen Berman wrote:
>>> Indeed, setting bidi-inhibit-bpa to t eliminates the delay.  Thanks.
>> Same here.
>>
>> And the "faster computer" didn't help, apparently.
>>
>> After flooring 'C-n', I even had to 'C-g' out of it for Emacs to regain
>> responsiveness, because waiting for a while didn't help.
> That's strange, because on my "slower" computer I didn't see anything
> like that.

I think that just confirms what I said: the test "floor the button and 
see of UI freezes" is not a good one because it doesn't work against any 
objective numbers. It compares the speed of command execution with the 
speed of redisplay, and there is no backpressure mechanism.

If the "faster computer" executes the commands faster as well, it can 
likewise enter the unresponsive state.




This bug report was last modified 2 years and 8 days ago.

Previous Next


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