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

Previous Next

Full log

View this message in rfc822 format

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

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

Previous Next

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