Re: cc-mode fontification feels random

[Alan Mackenzie <acm@muc.de>]

Hello, Daniel.

On Fri, Jun 04, 2021 at 11:30:09 -0700, Daniel Colascione wrote:
> On 6/4/21 8:54 AM, Alan Mackenzie wrote:
> >> Is there any *general* way that we can make fontification more robust
> >> and consistent?
> > Like other people have said on the thread, rewriting CC Mode to use an
> > LSP parser.

> > Less drastically, it would be possible to fix the specific bug you
> > allude to, by the user making a list of types and configuring CC Mode
> > with them, rather than attempting to recognise such types.  This feels
> > as though it would be tedious to use, though.

> I understand that cc-mode can't always get it right. It's only 
> asymptotically omniscient. :-) Some deficiencies in highlighting are 
> bound to happen.

> What's striking to me is the inconsistency in the highlighting. None of 
> the types in the std::variant declaration in my screenshot is special. 
> They're all declared in the same file as the std::variant typedef. So 
> why is PrimitiveType fontified while the others aren't?

Because of the order various jit-lock chunks are fontified.  If the
chunk which establishes foo as a type is fontified first, subsequent
fontifications of foo will use font-lock-type-face.  Otherwise, not.

> FWIW, fontification is correct and consistent when I set 
> font-lock-support-mode to nil, so this really does look like another 
> case of getting unlucky with jit-lock block divisions.

Maybe an improvement might come from scanning the buffer for occurrences
of foo after foo has been recognised as a type and entered into the CC
Mode table.  That way, the lack of fontification on foo would be
temporary, at least provided your Emacs is configured to fontify
non-displayed bits of the buffer in the background (which it is by
default).

This might need enhanced support from jit-lock, such as some sort of
signal indicating a buffer has been completly fontified.  I haven't
thought this through, yet.

> Yes, I'm sure that this particular problem is caused by some bug, and
> with the right repro, we can quickly isolate and fix it. But this kind
> of seemingly-inexplicable inconsistent highlighting has been happening
> for years and years now.  There's something fundamental about the way
> cc-mode is written that makes bugs like this keep popping up. Is there
> some internal abstraction we can add, some algorithmic test suite we
> can write, that would make this whole class of bug less likely?

Well, "seemingly-inexplicable inconsistent highlighting" isn't much to
go on.  If this means "problems with types not getting fontified", then
see above.  Otherwise, particulars help.  It may well be that the ad-hoc
parsing method which CC Mode uses is no longer appropriate for the
modern languages it supports; that's what a lot of this thread has been
discussing.  By "internal abstraction" I think you might mean getting
information from a compiler, or building a partial compiler into CC
Mode.  This is surely possible in theory, but in practice?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).