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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 14 Aug 2022 12:54:04 +0300

On 14.08.2022 08:29, Eli Zaretskii wrote:
>> Date: Sat, 13 Aug 2022 22:12:42 +0300
>> Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>>   Stefan Monnier <monnier <at> iro.umontreal.ca>
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> Moreover it does not offer any
>>> protection against modes which use widen in their font locking
>>> routines.  Which was the main reason to add the locked narrowing feature.
>>
>> The only modes we know that do that (CC Mode)
> 
> AFAIU, currently _all_ modes widen, because font-lock does.  That part
> was not yet fixed in font-0lock, was it?

The changes on the branch are right in that area:

-    (unless font-lock-dont-widen (widen))
+    (pcase-exhaustive font-lock-large-files
+      (`t nil)
+      (`(head . ,length)
+       (setq beg (min length beg)
+             end (min length end)))
+      (`(narrow . ,width)
+       (narrow-to-region (max (point-min) (* (1- (/ beg width)) width))
+                         (min (point-max) (* (1+ (/ beg width)) width)))
+       (setq end (min end (point-max)))))
+    (unless (or font-lock-dont-widen
+                (eq (car-safe font-lock-large-files) 'narrow))
+      (widen))

>> are also incompatible with your code. Your "protection" breaks it.
> 
> For some value of "breaks".
> 
> And that is a deliberate "breakage": we consider responsive Emacs more
> important than correct fontification or "accurate" operation of modes
> such as CC Mode.  As was already explained numerous times here, and
> arguing about that should by now be understood as being futile.
> People who disagree with that default can customize
> long-line-threshold to a larger value or to a nil value.

Due to its current way of operation, it might spam errors to the echo 
area, break some navigation commands, or even freeze. I imagine it'll be 
not so easy to rework that.

Though I'd of course welcome that: if you recall the older talks about 
switching it to the syntax-propertize approach, it's one way to do that.

Previous Next

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