bug#45898: 27.1; wedged in redisplay again

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Fri, 1 Jul 2022 06:42:23 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  larsi@gnus.org,
>  psainty@orcon.net.nz,
>  Emacs-hacker2018@jovi.net,
>  45898@debbugs.gnu.org
> 
> 
> [1:text/plain Hide]
> 
> 
> > On 2022-06-30,, at 21:56 , Stefan Monnier <monnier@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.

Or (on GNU/Linux only) under 'prof' -- which doesn't require you to
build a special version of Emacs, and still produces detailed CPU
usage info.