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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 31 Jul 2022 12:04:21 +0300

> Date: Sun, 31 Jul 2022 08:30:14 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked], 
>     [email-masked]
> 
> > 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.

But that assumes these hooks will _always_ be "too expensive" in such
buffers.  Which is not necessarily true: I can think of many things a
hook can do in a long-line buffer without being expensive.

And since we already remove expensive hook functions, maybe that is
enough?  Or maybe we should use a different threshold for "expensive"
in buffers with long lines?

> > 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.

I think we are in agreement: my point was that solving such problems
locally is not unthinkable.

> > 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.

Different thresholds are easy to reconcile: the optimizations should
be turned on if either of the two thresholds is exceeded.  But why do
you say the optimizations will be different? what's wrong with using
the same optimizations, i.e. restrict the display code from accessing
the entire buffer?