On 6/19/21 8:24 AM, Alan Mackenzie wrote:
>>> Sure. To be more precise: what I propose is not applying
>>> font-lock-type-face to symbols when we think that symbol is a type solely
>>> because it's been entered into cc-mode's table of dynamically discovered
>>> types for the current buffer.
>> OK, I'll make a trial implementation of this, controlled by a user option
>> to switch it on and off.  Give me just a little time.
> Would you please try the following, setting the new user option to nil,
> and let me know how well it meets expectations.  Thanks!
>
>
> diff -r 92a4592886a1 cc-engine.el
> --- a/cc-engine.el	Sun Apr 25 17:26:

Thanks. This patch is an improvement in the sense that there's more 
consistency in fontification. cc-mode is still very inconsistent in 
fontification though. Take a look at the attached screenshot, which is 
of this program:

void
deallocate_one_arg(void* const ptr_to_arg,
                    MethodProgramPc& pc);

void
deallocate_one_arg(void* const ptr_to_arg,
                    MethodProgramPc& pc);

I'm confused about why "MethodProgramPc" is fontified as a type in the 
first prototype but not the second. I still wish we had a 
general-purpose mechanism for ensuring that problems like this didn't 
happen.