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

Previous Next

Package: emacs;

Reported by: Devon Sean McCullough <Emacs-hacker2018 <at> jovi.net>

Date: Fri, 15 Jan 2021 18:14:01 UTC

Severity: normal

Found in version 27.1

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, psainty <at> orcon.net.nz, larsi <at> gnus.org, Emacs-hacker2018 <at> jovi.net, 45898 <at> debbugs.gnu.org
Subject: bug#45898: 27.1; wedged in redisplay again
Date: Fri, 01 Jul 2022 10:38:37 -0400
>> >> > That's only true if max-redisplay-ticks is zero.
>> >> 
>> >> Why would that make a difference?
>> >
>> > Because if it is not zero, we won't let the entire line to be
>> > fontified, we will stop that before it gets to the end of the line.
>> 
>> Interesting, where in the code do you do that?
>
> In scan_sexps_forward, near the end: if too many "ticks" are counted,
> update_redisplay_ticks will signal an error.  Same thing in
> re_match_2_internal.

Ah... neat, thanks!
Indeed, I can see the effect with:

    src/emacs -Q --eval '(setq syntax-wholeline-max most-positive-fixnum)' \
                 --eval '(setq max-redisplay-ticks 100000)'                \
                 ~/tmp/medium_line.json

in which case I get a warning about redisplay taking too long, whereas with:

    src/emacs -Q --eval '(setq max-redisplay-ticks 100000)' \
                 ~/tmp/medium_line.json

I don't (because the `syntax-wholeline-max` keeps the font-lock time
under control).


        Stefan





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.