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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked
 locked narrowing.
Date: Mon, 30 Jan 2023 20:56:15 +0200

On 30/01/2023 19:11, Eli Zaretskii wrote:
>> Date: Mon, 30 Jan 2023 15:03:54 +0000
>> From: Gregory Heytings<gregory <at> heytings.org>
>> cc:56682 <at> debbugs.gnu.org,monnier <at> iro.umontreal.ca
>>
>>> What exactly will that remove? only what's on the feature branch, or
>>> also some stuff on the emacs-29 branch?
>> The "locked narrowing" feature, IOW, the portions of editfns.c in which it
>> is implemented, and its use around pre-command-hook, post-command-hook and
>> fontification-functions.
>>
>>> And what are your reasons for removing this?  It is hard to tell whether
>>> or not I agree without knowing to what I should agree 😉
>>>
>> The reason is that I'm now convinced that it is not a good solution to the
>> problem of ill-behaving modes in the presence of long lines.
> So we are removing all the stuff that prevented font-lock from slowing
> down redisplay when long lines are in the buffer?  IOW, something
> which we have for several months, and which so far brought up only one
> complaint?

More than one, FTR.

I'm not 100% sure what Gregory's plan is, but note that a significant 
part of the redisplay slowdowns wasn't caused by font-lock, and thus the 
removal of locking will not regress those performance improvements.

And for those (potential?) cases where font-lock is a real problem for 
performance, we could stop it from widening using an existing knob.

Previous Next

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