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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gregory@heytings.org,  56682@debbugs.gnu.org
> Date: Sat, 23 Jul 2022 10:07:29 -0400
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: Gregory Heytings <gregory@heytings.org>,  56682@debbugs.gnu.org
> >> Date: Fri, 22 Jul 2022 19:25:47 -0400
> >> 
> >> For example, the behavior surprises me because I can't see why `M-x`
> >> should cause any font-locking at all in the `long-line.xml` file.
> >
> > Any command that enters the minibuffer causes a thorough redisplay of
> > the windows on that frame (because more than one window has to be
> > updated).  What does that have to do with font-lock is a separate
> > question (but you are the best person to answer it).
> 
> AFAIK if the buffer has not been modified (including things like
> changing `window-start` or `point`), then a redisplay will just not
> run jit-lock (and hence font-lock) at all, no matter how thorough.

But the fact is without font-lock the response is faster by a large
factor.  So something, somewhere, still depends on font-lock.