Re: POC: customizable cc-mode keywords

[Alan Mackenzie <acm@muc.de>]

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.

> 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.  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.

> 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?

> As implemented, the keyword list can only be customized globally, but
> it'd be nice to be able to do something buffer-local too.

[ snipped patch for now. ]

-- 
Alan Mackenzie (Nuremberg, Germany).