GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1051 received at 56682 <at> debbugs.gnu.org (full text, mbox):
On 05.08.2022 16:41, Gregory Heytings 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.
>>
>
> Other editors just give up syntax highlighting altogether even with the
> 18 MB file (and you cannot edit really large files with them).
In my testing, with my patch, the 18 MB file works reasonably well and
has good syntax highlighting.
> But if you're so annoyed by mis-fontification, why don't you just turn
> font-lock mode off?
"If you're annoyed by Emacs's performance with large files, why don't
you just never open them?"
I like font-lock and the visual cues that come with it. Only
font-locking the first 1 MB of a large file seems like a good
compromise: show correct highlighting where we can with reasonable
performance, and omit it in the rest of the file.
> Also, why did you not protest vehemently when Stefan added
> syntax-wholeline-max, which also causes occasional mis-fontification?
I have replied to this exact question in an earlier email. We can
continue this line of inquiry in that subthread.
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.