|
From: | Dmitry Gutov |
Subject: | bug#56682: Fix the long lines font locking related slowdowns |
Date: | Fri, 5 Aug 2022 16:30:17 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 |
On 05.08.2022 16:17, Stefan Monnier wrote:
What I'm not sure of is how useful is a "font-lock with arbitrary narrowing", where portions will be highlighted as strings rather than code (and vice-versa). I don't have enough experience with it yet to be sure. Taking a step back, I suspect that the only "real" solution is something like `jit-lock-defer` coupled with a way to perform the font-lock (and syntax-ppss/propertize) in the background.
IIRC I heard that "some other editors" take the approach of restricting syntax-highlighting to just the beginning of a large file.
10000 seems too low, but if the 2 seconds in the dictionary.json example feels too much to people (and the file is 18 MB), maybe restrict syntax highlighting to the first 1 MB of each file? At least until someone optimizes parse-partial-sexp to work much faster.
Or 10MB. Not too important as long as the value is separately customizable.Anyway, I think I'd prefer no highlighting at the end of those large files, rather than arbitrarily incorrect one.
[Prev in Thread] | Current Thread | [Next in Thread] |