Re: POC: customizable cc-mode keywords

[Alan Mackenzie <acm@muc.de>]

Hi, Daniel.

On Sun, May 11, 2014 at 02:23:15PM -0700, Daniel Colascione wrote:
> 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.

OK, so we need to have configurable "noise macros", just as we already
have configurable "macros ending with a semicolon" and "extra types".

[ .... ]

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

Turning the pertinent c-lang-defvars, and only these, into configurable
variables in cc-vars.el.

[ .... ]

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

I'm sorry, but I can't make much of that paragraph; it doesn't seem
coherent to me.  What I still don't understand is why it should be
necessary to make _all_ c-lang-defvars configurable variables, rather
than just those one or two directly involved in parsing these awkward C
(etc.) declarations.

As I said, I'm not at all happy at making such a massive change to CC
Mode's architecture.  There would surely be unforeseen consequences, some
of which might well be negative.

-- 
Alan Mackenzie (Nuremberg, Germany).