GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1558 received at 56682 <at> debbugs.gnu.org (full text, mbox):
On 15.08.2022 22:36, Gregory Heytings wrote:
>
>>
>> No, I want a simple variable that just gives the size of the narrowed
>> region, with nil meaning don't narrow at all.
>>
>
> FWIW, I strongly object to the addition of such a variable (unless it is
> clearly stated that it is added temporarily and should not be used
> except for testing purposes).
>
> Adding such a variable only two weeks after locked narrowing has been
> introduced means that modes will have little incentive to adapt to that
> stronger constraint, if they can "fix" whatever problems that constraint
> might cause by setting that variable to nil in their initialization hooks.
I don't think major modes would take advantage of that var. I hope not,
at least.
> We did not have enough time yet to explore whether and how syntax-ppss
> can be improved.
If you wanted the development to take this route, it would have really
made more sense to hold off on applying the narrowing to
fontification-functions, keeping font-lock slow-ish in large files. That
would have encouraged direct work on speeding it up.
But anyway. Suppose we have some more success with syntax-ppss. Two options:
1) parse-partial-sexp is now faster by 10x. That just means we have 10x
larger files to deal with.
2) We have learned to find a "safe position" in some file types, to
avoid the full scan from the beginning. It's not hard to implement that
for JSON and XML, as long as we can stand _some_ imprecision. But there
will remain all other file types for which nobody has written such logic.
In both cases we fall back to something. And the preceding discussion
has concluded that that something is narrowing.
This bug report was last modified 2 years and 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.