|
From: | Dmitry Gutov |
Subject: | bug#56682: Fix the long lines font locking related slowdowns |
Date: | Sun, 14 Aug 2022 21:14:00 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 |
On 14.08.2022 21:01, Eli Zaretskii wrote:
Date: Sun, 14 Aug 2022 20:51:14 +0300 Cc: 56682@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca From: Dmitry Gutov <dgutov@yandex.ru>If the conclusion is, after some reasonable effort, that there is no way to make syntax-ppss significantly faster in one way or another in such cases, and that there is no way to make font locking reasonably accurate even when it doesn't have access to the whole buffer, it might make sense to provide user options to fine-tune the behavior. But we are not there yet.Both conclusions lead to removing the applications of narrowing from handle_fontified_prop.We will not remove that, no.
Please look at the branch. It moves the (potential) narrowing from C to Lisp.
So how about we either do that (defaulting to accurate font-lock), or merge the branch I proposed, and then continue on to the more complex developments?Please wait with requests to merge until I had time to review the branch.
Waiting, and thanks.
Implementing the "font locking reasonably accurate even when it doesn't have access to the whole buffer" would also have to be implemented in Lisp, so narrowing outside of font-lock doesn't make sense.Cannot parse this, sorry. I guess some typo?
The implementation of the idea that Gregory mentioned (font locking reasonably accurate even when it doesn't have access to the whole buffer) will have to be done in Lisp anyway. So that's where the narrowing should be applied too.
Does that parse? Not sure how to phrase it better.
[Prev in Thread] | Current Thread | [Next in Thread] |