bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 14 Aug 2022 12:54:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

On 14.08.2022 08:29, Eli Zaretskii wrote:
Date: Sat, 13 Aug 2022 22:12:42 +0300
Cc: 56682@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
  Stefan Monnier <monnier@iro.umontreal.ca>
From: Dmitry Gutov <dgutov@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]