bug#56682: Fix the long lines font locking related slowdowns

[Dmitry Gutov]

On 27.07.2022 09:55, Gregory Heytings wrote:
> > But I'm seeing incorrect fontification. Is this one expected?
>
> Yes, occasional mis-fontification is expected.  It's a compromise 
> between "no fontification" and "slow fontification".

I wonder now if the majority of the slowdown was caused by the 
redisplay, whereas font-lock (which only has to run once per screenful) 
was actually "fast enough".

> > Perhaps something to do with the number 40000?
>
> There is no magical number 40000 in the implementation, the buffer 
> limits to which fontification-functions are constrained are determined 
> dynamically, depending on the width and height of the window.
>
> My guess in this specific case is that the first instance of 
> "Downloadify.Container" was fontified by the previous call to 
> fontification-functions, and that the next chunk of text in which the 
> two other instances of "Downloadify.Container" are contained was 
> fontified by the next call to fontification-functions, which did not 
> have access anymore to the place where Downloadify.Container is defined.

Could you clarify what you mean by "access ... to the place where ... is 
defined"? "new Downloadify.Container" is highlighted by a regular regexp 
matcher, not some custom elisp code which has to visit the position 
where the identifier is defined.

Same goes for the tokens like "null", "function" and "return", but those 
do get fontified after position 40000 in this example.

And the way those rules get applied doesn't seem particularly different, 
it's just that the keyword matcher goes before the class instantiation 
matcher inside js--font-lock-keywords-3.