Re: cc-mode fontification feels random

[Alan Mackenzie]

Hello, Eli.

On Thu, Jun 10, 2021 at 09:39:06 +0300, Eli Zaretskii wrote:
> > 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.

Yes, it does make a difference.  On my machine, the times to scroll
through xdisp.c with my favourite benchmark for
font-lock-maximum-decoration set to 3, 2, 1 are 23s, 7.5s, 5.5s.

> > 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?

Maybe.  It seems, though, that f-l-max-decoration is primarily about the
degree of fontification applied, not its accuracy.

> > > > "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?

Well, I care for my own personal use, because the type fontifications
help optically to separate the different parts of a function without
needing to look too hard.  The coloured bits are the variable
declarations, to a zeroth order approximation.  I suspect different users
have very different needs here.  Doesn't RMS run with font lock switched
off (or is that just a rumour)?

> > > 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.

That would be difficult.  Frequently a bug fix involves extensive code
changes rather than simply a block of code one could put an `if' around.

> > > 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?

They're not of any particular kind.  Any bug fix could slow CC Mode down
marginally.  Some have been known to speed it up.

> If they only cause imperfect faces, I'm not sure it's unthinkable to
> disable them, given some optional value of a user knob.

Well, I've fixed around 550 bugs in CC Mode in the last 20 years.
Identifying and reversing a subset of these to revert the performance
would be difficult.

> > 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.

You could set it buffer locally in c-mode-common-hook, for example.  It
won't solve the basic problem, but it might brighten your day up.

-- 
Alan Mackenzie (Nuremberg, Germany).