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

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 16 Aug 2022 08:26:49 +0000

>>> No, I want a simple variable that just gives the size of the narrowed 
>>> region, with nil meaning don't narrow at all.
>>
>> FWIW, I strongly object to the addition of such a variable (unless it 
>> is clearly stated that it is added temporarily and should not be used 
>> except for testing purposes).
>>
>> Adding such a variable only two weeks after locked narrowing has been 
>> introduced means that modes will have little incentive to adapt to that 
>> stronger constraint, if they can "fix" whatever problems that 
>> constraint might cause by setting that variable to nil in their 
>> initialization hooks.
>
> Modes can do that already by changing long-line-threshold to nil, don't 
> they?
>

They can indeed, but that variable is documented as "for debugging 
purposes" only.  Moreover setting that variable to nil implies that they 
deactivate all long line optimizations, which is a higher price to pay.

The way I see this is that Emacs is doing efforts to solve editing 
slowdowns as best as possible, but that there is a "last mile" that cannot 
be solved without the collaboration from major and minor modes.

Previous Next

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