bug#56682: Fix the long lines font locking related slowdowns

[Eli Zaretskii]

> Date: Tue, 16 Aug 2022 08:26:49 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru
> 
> >> 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.

That never stopped anyone, IME.

> Moreover setting that variable to nil implies that they 
> deactivate all long line optimizations, which is a higher price to pay.

They could do that only locally in one buffer, or temporarily, or just
set it to a much larger value, or ...

> 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.

I'm not worried by that: we do control what code gets installed in the
modes that are part of Emacs, so we can always prevent any such modes
from (ab)using these variables.  And if third-party packages want to
do that, in effect harming their users, it's eventually their funeral.