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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 02 Aug 2022 22:14:56 +0000

>> I see what you mean now.  But I don't think it would work.  What I want 
>> is to take reasonable measures to ensure that Emacs remains responsive 
>> "in spite of" mode maintainers.
>
> "Reasonable measures" is good.
>
> But once you step into "impossible to circumvent", you start going 
> directly against the goals of Free Software (and Emacs) to empower the 
> user.
>

But it is *not* impossible to circumvent.  Just add (setq 
long-line-threshold nil) in your init file, or evaluate it with M-:, or...

>
> I suffer from the same lack of imagination, as I sure many others here 
> do.  To make up for that, we've learned to follow a philosophy of 
> empowering the users (and not imposing arbitrary limits just because we 
> couldn't think of good reasons to go beyond them).
>

I'm all for empowering the users who want power, and the changeset is, 
intentionally, fully backward compatible.  In fact, strictly speaking, 
this changeset does exactly that: it empowers users, they can do things 
they couldn't do earlier.  But I'm also for protecting regular users who 
want a powerful editor that "just works".  In the same vein, we are 
marking a number of local variables as risky, to protect regular users, 
without preventing users from shooting themselves in the foot by adding

(defalias 'risky-local-variable-p 'ignore)

in their init file if they see fit.

Previous Next

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