Re: cc-mode fontification feels random

[Daniel Colascione]

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?

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.

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?
> > For years and years now, I've been thinking we just need more
> > deterministic parser-and-based mode support, and I still think that, but
> > on a realistic level, that doesn't seem to be coming any time soon.
> What does "parser-and-based" mean?

I'd meant to type "parser-and-ast" I think.

> > In the meantime, is there any general approach we might be able to use
> > to get stuff like the attached to stop happening?
> Probably none that we'd like.  Fontifying types only at their point of
> declaration would be one, but I don't think people would want that.  My
> impression is that the approach taken by CC Mode, like that of most
> language modes in Emacs, has pretty much reached the limits of what's
> possible, and it is unreasonable to expect perfect fontification (and
> indentation) from languages like C++ in all cases.