GNU bug report logs - #45898
27.1; wedged in redisplay again

Previous Next

Full log

Message #116 received at 45898 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, Emacs-hacker2018 <at> jovi.net,
 45898 <at> debbugs.gnu.org
Subject: Re: bug#45898: 27.1; wedged in redisplay again
Date: Thu, 23 Jun 2022 17:14:50 -0400

>> > Are you saying that many regular expressions in font-lock-keywords are
>> > anchored at beginning or end of a line?
>> No but for example if the 10000 char boundary falls in the middle of the
>> word "function", then all the highlighting rules which rely on matching
>> the keyword "function" will fail.
> So we value accurate fontification more than we value a usable Emacs
> session?

There was no value judgment in my answer :-)

>> For such huge files, it's arguably more important to be more-or-less
>> usable than it is to get the highlighting right, so there's a good case
>> for turning off font-lock or breaking it somewhat by using arbitrary
>> limits in the handling of `font-lock-extend-region-functions` in
>> `font-lock-default-fontify-region`.
> I'm talking about cases where the user visits such files without
> knowing in advance that he/she has better turned off font-lock there.
> I'm asking whether one of the things we could do when we discover that
> parse-partial-sexp is called for such a large chunk of text could be
> automatic introduction of such a limit only for that buffer, so that
> font-lock won't be such a significant part of the reason for redisplay
> slowness in these cases.

Yes, that's exactly what I'm proposing in the paragraph you quoted.
I think it makes sense to bound the growth of the region due to
`font-lock-extend-region-functions`.  We could bound it where we handle
`font-lock-extend-region-functions`, or we could bound it just inside
`font-lock-extend-region-wholelines`.

> Also, can you tell why visiting the same file in Text mode doesn't
> produce the same effect?

Probably because it doesn't setup font-lock mode?

> I guess this is related to font-lock
> settings of js.el, but my question is: would any mode that uses
> syntactic fontification be similarly affected, or is there anything
> special with js.el specifically?

I think pretty much any major mode would be affected.  It can be more or
less severe depending on how much work is done inside
`font-lock-keywords` (and `syntax-propertize`), but by and large I'd
expect it to suck for all non-trivial modes.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.