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

[Gregory Heytings]

> It sounds...too drastic.

Are you sure?  The docstring already says "It is a bad idea to use this 
hook for expensive processing."  And Emacs already removes a function from 
the hook when it misbhaves.  Adding something like "In a too large buffer 
or in a buffer with long lines, the functions in this hook will only have 
access to a small portion of the buffer" seems coherent, at least to me.

> Once again, IME it is impossible to fix such problems only in low-level 
> C infrastructure.  There will always be left-overs and fallouts that 
> should be fixed locally in Lisp where they happen. There's no problem 
> here, and I don't expect us to be able to fix everything by a small 
> number of quick fixes, and declare a victory once and for all.

I both agree and disagree with that.  It is true that it is, strictly 
speaking, impossible to fix _all_ such problems _only_ in low-level C 
intrastructure, and that there will always be left-overs.  But it is 
possible to fix _most_ of these problems only in low-level C 
infrastructure, and we should do so, just like an operating system kernel 
in which everything is done to avoid crashing the system/leaving it in an 
unusable state (which includes killing a mis-behaving process when 
necessary).  And we should do so even more when the amount of code to do 
so in the low-level C infrastructure remains small.

> Well, WDYT about a similar feature for very large files?  IOW, when the 
> buffer's size is above some threshold, turn on the 
> long_line_optimizations_p flag (which should perhaps be renamed to 
> better reflect its purpose) even if no long lines are seen?

I was thinking about such a feature indeed.  But it would be separate from 
the long_line_optimizations_p one, because the optimizations to activate 
in both cases are different, and their thresholds are different, too.