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


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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked
 locked narrowing.
Date: Mon, 30 Jan 2023 23:07:22 +0200
On 30/01/2023 21:02, Eli Zaretskii wrote:
>> Date: Mon, 30 Jan 2023 20:56:15 +0200
>> Cc:56682 <at> debbugs.gnu.org,monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> 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.
> Yes, this is an old and known disagreement between us.  But this is my
> decision to make, not anyone else's.

With the previous change that Gregory had made (different limits for 
different features, i.e. font-lock uses much wider narrowing bounds 
which are also customizable) I don't have that much of a horse in that 
race anymore.

Just helping clear up some misconceptions, if any.

Also note that previously, I'd never have suggested that redisplay code 
changes the value of font-lock-dont-widen.




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.