Re: cc-mode fontification feels random

[Eli Zaretskii]

> Date: Fri, 11 Jun 2021 20:06:30 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, dancol@dancol.org,
>   rudalics@gmx.at, rms@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Why do we have a problem?  If the time taken to fontify a window is less
> than the auto-repeat time (the two times are close on a modern machine),
> this is surely not a problem for somebody with such a machine.  It could
> be a problem for somebody with a slower machine, or running an
> unoptimised Emacs.

It is a problem given how much the current fast machines can do during
that time.  At 3 GHz, 30 msec of CPU time is equivalent to 100 million
machine instructions.

> > That is much better, but still too slow, IMO.  Think: it's the time
> > that it takes us to fontify a single windowful, only a couple of
> > dozens of lines.  Why does it take so long?
> 
> It does a very thorough job.


AFAIU, sm-c-mode doesn't.  And it still takes tens of milliseconds.

> For example, one bug fix from many years
> ago that I remember involved the fontification of foo in the following:
> 
>         ....
>         int bar;
>     } foo;
> 
> What face should foo have?  To answer that, you've got to go back over
> the brace expression to see what's there.  If it's
> 
>     struct foo
>     {
>         int baz;
>         ....
> 
> , we need font-lock-variable-name-face for foo.  On the other hand, if we
> have
> 
>     typedef struct foo
>     {
>         int baz;
>         ....
> 
> , we need font-lock-type-face.  Before the bug fix, foo just got variable
> name face.  scan-lists backward over the brace expression takes time,
> particularly for something the size of struct frame or even bigger.

We should either find a way of making this analysis faster, or give up
on fontifying these two cases differently.  It is IMO unacceptable
that redisplay is slowed down so much by mode-specific fontifications.