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

[Dmitry Gutov]

On 26.07.2022 09:52, Gregory Heytings wrote:
> > With font-lock, it seems to get progressively slower the farther you 
> > get along the current (long line).
> >
> > E.g. you can have a long line spanning several screenfuls without line 
> > breaks. When the window is scrolled to the beginning, redisplay is 
> > relatively fast (I can press up/down arrows, and they seem responsive).
> >
> > But if I scroll the window to the end of said long line, up/down 
> > commands become much less responsive.
> >
> > Tested that with today's master and js-mode visiting a minified JS file.
>
> You should have tried the feature/long-lines-and-font-locking branch 
> instead, where that problem has been fixed a few hours ago.

I've tried that one now.

The performance is indeed much better (thanks!). But I'm seeing 
incorrect fontification. Is this one expected?

Attached are two screenshots: of a buffer fontified, and of it with 
'isearch' for the exact text I'm referring to (for convenience).

I expect all of the occurrences to be fontified the same, but "new 
Donloadify.Container" occurrences stop being highlighted somewhere 
between the buffer positions 37414 and 40203.

Perhaps something to do with the number 40000?

But it's not like all syntax highlighting stops: other rules seem to 
continue to be applied. Perhaps there is a reason for it to fail, or 
it's some subtle bug which could be improved further.

The rule itself seem to be defined at line 1740 in lisp/progmodes/js.el. 
Under the comment that says "class instantiation".

Screenshot from 2022-07-27 00-02-32.png
Description: PNG image

Screenshot from 2022-07-27 00-02-38.png
Description: PNG image