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: Gregory Heytings
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 30 Jul 2022 13:17:25 +0000


I'm not opposed to reducing the size of the text that's considered, but
doing it via narrowing is a blunt tool.

It isn't.

There's no point arguing about it. I find it to be and you don't and that's that.


Actually, with your explanation below that "blunt" means for you "cannot be fine-tuned", I agree with you.


The reason why I find it to be is because it removes all possibilities of making different choices for different elements depending on the cost of those elements and the amount of available information.


With that I also agree. It would be better to have a refined decision method, but at the moment it doesn't exist.


What I think would be a better option is to (somehow) pass the `beg..end` "limit" to jit-lock which can then pass it on to its own clients (e.g. font-lock) so they each can make their own choices.


I sent a patch a few hours ago in this thread.

The limit of what you suggest is that its effect would depend on the goodwill of major and minor mode authors, which could decide to ignore these beg..end recommendations altogether. Whereas the point of that feature is more or less to protect Emacs users from major and minor modes, to make sure that Emacs remains responsive when the buffer contains long lines.

Also, there are other users of fontification-functions besides jit-lock-function.

(And for some reason the patch I sent does not give the results I would have expected, font-locking is still too slow, but it's perhaps a bug in the patch.)


E.g. the syntax-ppss part of the job performed by font-lock is heavily cached, does not depends on lines, is theoretically always computed from BOB but with a cache which makes it fast even when working near EOB (tho it can still be somewhat slow when jumping from BOB to EOB, but that depends on the size of the buffer, not the size of lines). This part *should* ignore your limits, which will make sure comments and strings are recognized correctly at least in simple cases (i.e. cases which don't depend on `syntax-propertize-function`).


I see. Do you see a way to somehow extract the syntax-ppss part out of font-lock? Would that be feasible?

And another question: can syntax-ppss not be used to determine a "good starting position" for the narrowing, outside of any comments or strings (if possible)?





reply via email to

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