Re: cc-mode fontification feels random

[Eli Zaretskii]

> Date: Wed, 9 Jun 2021 21:03:03 +0000
> Cc: dancol@dancol.org, monnier@iro.umontreal.ca, rudalics@gmx.at,
>   emacs-devel@gnu.org, rms@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > That's why we had (and still have) font-lock-maximum-decoration: so
> > that users could control the tradeoff.  Unfortunately, support for
> > that variable is all but absent nowadays, because of the widespread
> > mistaken assumption that font-lock is fast enough in all modes.
> 
> That variable is still supported by CC Mode (with the exception of AWK
> Mode, where it surely is not needed).

Does it make a difference, performance-wise?  If not (which is what
ISTR), then that variable isn't really "supported", because supporting
it means that different values of it cause tangible differences in
performance.

> Another possibility would be to replace accurate auxiliary functionality
> with rough and ready facilities.  In a scroll through xdisp.c, fontifying
> as we go, the following three functions are taking around 30% of the
> run-time:
> 
> (i) c-bs-at-toplevel-p, which determines whether or not a brace is at the
>   top level.
> (ii) c-determine-limit, c-determine-+ve-limit, which determine search
>   limits approximately ARG non-literal characters before or after point.
> 
> By replacing these accurate functions with rough ones, the fontification
> would be right most of the time, but a mess at other times (for example,
> when there are big comments near point).  (i) is more important for C++
> that C, but still makes a difference in C.
> 
> If we were to try this, I think a user toggle would be needed.

How about making font-lock-maximum-decoration control that as well?

> > > "Shouldn't try to guess" means taking a great deal of
> > > font-lock-type-faces out of CC Mode.  I don't honestly think the end
> > > result would be any better than what we have at the moment.
> 
> > You don't think it will be better for what reason?
> 
> Because many users will still want at least the basic types (int, double,
> unsigned long, ....) fontified

I'm not sure.  Can you explain why would I care too much about the
basic types (or types in general) standing out?

> > If there's no way of fixing a bug without adversely affecting speed,
> > we should add user options to control those "fixes", so that people
> > could choose the balance that fits them.
> 
> I think this would be a bad thing.  There are no (or very few) similar
> user options in CC Mode at the moment, and an option to fix or not fix a
> bug seems a strange idea

It depends on the bug.  If the bug causes Emacs to infloop or work
very slowly, then sure, no toggle for the fix would make sense.  But I
was talking about "bugs" that cause inaccurate or incorrect
fontifications, and those are much "softer".  At least IMO such "bugs"
are tolerable if they are rare enough, especially if fixing them hurts
redisplay performance and Emacs responsiveness in general.

Don't forget that the display code invokes fontifications also when it
does internal layout calculations whose results are not immediately
shown (or even not at all).  When that happens, some command not
directly related to display could be adversely affected.  So one idea
would be to turn off these expensive parts in those cases.

> > Once again, a pathological use case should not punish the usual ones;
> > if the punishment is too harsh, there should be a way to disable the
> > support for pathological cases for those who never hit them.
> 
> The punishment is rarely too harsh for a single bug.  But a lot of 2%s,
> 3%s or 5%s add up over time.  If we were to outlaw a "3% fix", then many
> bugs would just be unsolvable.

Once again: what kind of "bugs" are those?  If they only cause
imperfect faces, I'm not sure it's unthinkable to disable them, given
some optional value of a user knob.

> Do you have fast-but-imprecise-scrolling enabled?

No.  That's a separate issue, and influences all the modes, even those
where font-lock is light-weight.