GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
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)?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.