[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45898: 27.1; wedged in redisplay again
From: |
Eli Zaretskii |
Subject: |
bug#45898: 27.1; wedged in redisplay again |
Date: |
Fri, 01 Jul 2022 08:27:24 +0300 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gerd.moellmann@gmail.com, larsi@gnus.org, psainty@orcon.net.nz,
> Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org
> Date: Thu, 30 Jun 2022 15:56:41 -0400
>
> >> Unsuprisingly so: none of `C-n/C-p/C-v/...` involve font-lock or
> >> jit-lock either during their operation or during the
> >> subsequent redisplay phase in the current code: the one-line is all
> >> fontified once and for all when you open the file and after that
> >> font-lock is not involved any more (until you make an edit, that is).
> >
> > 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.
> When I try `master` with this set to
> 100000, the file still shows up with font-locking, so apparently it's
> been fully font-locked despite `max-redisplay-ticks`
You see only a small portion of the file.
> and after that
> font-locking (and syntax-propertize) won't make any difference any more
> (until the buffer is edited) since they're already done.
> [ Of course font-locking (and syntax-propertize) still do have an
> effect in that the text-properties they applied can impact the time it
> takes for the redisplay to do its job; so by "won't make any difference"
> I mean that 0-cycles will be spent running font-lock of
> syntax-propertize code. ]
Sorry, I cannot parse this at all.
- bug#45898: 27.1; wedged in redisplay again, (continued)
bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/07/01
bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/07/01
bug#45898: 27.1; wedged in redisplay again,
Eli Zaretskii <=