On 05/11/2014 02:13 PM, Alan Mackenzie wrote:
> Hi, Daniel.
> 
> On Thu, May 01, 2014 at 10:26:07PM -0700, Daniel Colascione wrote:
>> cc-mode has trouble with parsing dialects of C that use the preprocessor
>> heavily.
> 
> This has been true since 4004 BC, since C hackers are able to write
> monstrosities using macros.  But we do our best to cope with the less
> outlandish variants.

We have to address the syntactic confusion these macros cause somehow,
and I don't think automatic heuristics will be sufficient. I'm really
sick of seeing a lot of code I look at in the real world misfontified.

>> Consider this example from the Linux kernel:
> 
>>   static int perf_event_period(struct perf_event *event, u64 __user *arg)
> 
>> __user is defined to some GCC static analysis nonsense, but since
>> cc-mode doesn't know that, we see __user fontified in
>> font-lock-variable-name-face and *arg untouched. This example is fairly
>> benign (if ugly), but there are other cases where variations in
>> pre-processor C dialect confuse cc-mode in larger regions, leading to
>> odd fontification and indentation.
> 
>> The patch below adds customizable options for additional C-family
>> language "keywords".
> 
>> To add this feature, we have to change how cc-mode evaluates its
>> language variables.
> 
> :-)
> 
>> Today, we use clever macros to hard-code the values of all cc-mode
>> language variables into the mode functions of each cc-mode major mode
>> function or into c-init-language-vars-for, but in order to allow users
>> to customize cc-mode syntax, we have to be able to recompute language
>> constants and variables at runtime.
> 
> Do we, now?  You can imagine I've one or two reservations about this
> idea. 

What's your alternative?

> It's far from clear that this level of customisation is a good
> thing.  The current idea is that the language variables are for creating
> new CC Mode languages, not as a means of customisation.

They're public either way.

>> The new code simply evaluates cc-mode language setter forms at mode
>> initialization instead. This approach is slower, but not by much: it
>> takes 0.9ms to set up cc-mode's ~130 language variables using the
>> precompiled function approach, while it takes 1.6ms to do the same work
>> using dynamic evaluation. I can live with this performance regression.
> 
> Have you considered turning the pertinent language variables into
> customisable variables in cc-vars.el, along the lines of
> *-font-lock-extra-types?

The patch includes user-customizable variables. The actual cc-lang
constants aren't advertised as user customization points. The existing
type customization is simple because it's done in isolation from the
rest of cc-mode's syntactic analysis. Actually understanding keywords
requires deeper, cascading changes to core language constants. The only
practical way of making that happen is to allow these constants to
change at runtime.