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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: psainty <at> orcon.net.nz, Eli Zaretskii <eliz <at> gnu.org>,
 Emacs-hacker2018 <at> jovi.net, larsi <at> gnus.org, 45898 <at> debbugs.gnu.org
Subject: Re: bug#45898: 27.1; wedged in redisplay again
Date: Fri, 1 Jul 2022 06:42:23 +0200

[Message part 1 (text/plain, inline)]

> On 2022-06-30,, at 21:56 , Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> 
>>> 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?  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` 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.  ]

Would it be possible to run this with gprof profiling?  I think that could give some clues what is going on.

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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