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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 23 Jul 2022 18:29:39 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Sat, 23 Jul 2022 10:07:29 -0400
> 
> >> From: Stefan Monnier <[email-masked]>
> >> Cc: Gregory Heytings <[email-masked]>,  [email-masked]
> >> 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.