Subject: Re: bug#45898: 27.1; wedged in redisplay again

From: Eli Zaretskii <[email-masked]>
Date: Wed, 22 Jun 2022 05:33:24 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: Lars Ingebrigtsen <[email-masked]>,  [email-masked],
>   [email-masked],  [email-masked]
> Date: Tue, 21 Jun 2022 16:38:59 -0400
> 
> > One surprising finding is that sometimes syntactic fontifications
> > (triggered via jit-lock.el as part of rendering the buffer) seem to
> > run amok: jit-lock asks the mode's fontification to fontify a
> > 1500-character block, but that results in parse-partial-sexp being
> > called to parse the entire humongous file, BOB to EOB.
> 
> IIUC the file is a single long-line.  Font-lock works line-by-line (in
> theory major modes can override that by providing their own value for
> `font-lock-extend-region-functions`, but regexp-based fontification is
> hard to do with our regexp enging if not working line-by-line), so even
> if jit-lock only requests fontification of a 1500-char block, font-lock
> rounds it up to a whole number of lines (and then proceeds to call
> `parse-partial-sexp), which would explain what you're seeing.

Isn't there a way to limit what font-lock considers a "line" such that
it doesn't consider more than some number N of characters?  What could
potentially happen if we set N to, like, 10,000 characters?  Are you
saying that many regular expressions in font-lock-keywords are
anchored at beginning or end of a line?

And even if the regexp-based font-lock needs to do it line-by-line,
does it really _have_ to invoke parse-partial-sexp for the entire
line, when doing syntactical fontifications? why is that?