bug#45898: 27.1; wedged in redisplay again

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  psainty@orcon.net.nz,
>   Emacs-hacker2018@jovi.net,  45898@debbugs.gnu.org
> 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?