GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1426 received at 56682 <at> debbugs.gnu.org (full text, mbox):
On 14.08.2022 21:01, Eli Zaretskii wrote:
>> Date: Sun, 14 Aug 2022 20:51:14 +0300
>> Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>> monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> 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.
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.