Re: POC: customizable cc-mode keywords

[Daniel Colascione]

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.

signature.asc
Description: OpenPGP digital signature