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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Gregory Heytings [2022-08-16 14:03:16] wrote:
>>> Without assuming that computers have infinitely fast CPUs, that is?
>> If the font-lock rules to use in the buffer depend on whether the first
>> line of the buffer starts with #! or not, then your narrowing will break
>> them even tho they could work perfectly fine in a 1TB buffer without
>> requiring an infinitely fast CPU (since they don't need to scan the whole
>> buffer: just the region of interest plus the first 2 chars).
> Why on earth should a font-lock rule check, inside each redisplay cycle,
> whether the first line of the buffer starts with #! or not?

[ Nitpick: font-lock is not triggered "inside each redisplay cycle".  ]
Because it's simple and efficient.

> Isn't that an information that can, and in fact should, be cached?

"Can" maybe, "should" probably not since managing the cache will be
more trouble than it's worth.

Also, in your case you'd need that info to always be up-to-date, in
which case it's not really a "cache" (since that word usually refers to
something that may be available but isn't guaranteed to be so, and is
re-filled lazily), but a redundant representation of the data (which is
usually more costly to manage).


        Stefan