GNU bug report logs -
#45898
27.1; wedged in redisplay again
Previous Next
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, psainty <at> orcon.net.nz,
> Emacs-hacker2018 <at> jovi.net, 45898 <at> 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?
This bug report was last modified 2 years and 357 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.