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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
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: Fri, 24 Jun 2022 10:57:30 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org,  psainty <at> orcon.net.nz,  Emacs-hacker2018 <at> jovi.net,
>   45898 <at> debbugs.gnu.org
> Date: Thu, 23 Jun 2022 17:14:50 -0400
> 
> >> 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`.

I hope this will be done soon.

I've landed the feature on master, let me know (everyone, not just
Stefan) how it fares.

Gerd, your comments will be most appreciated, TIA.

> > 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.

For now, you will see that the code I installed "punishes" syntax.c
for exploring too many character positions, hope this is "good enough"
for the relevant pathological situations.

Previous Next

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