GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1663 received at 56682 <at> debbugs.gnu.org (full text, mbox):
> 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.
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.