On 05/16/2014 10:52 AM, Alan Mackenzie wrote:
>>>> 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.

Have you looked into what task actually involves? You need to modify
c-decl-hangon-kwds, and as a result, c-prefix-spec-kwds,
c-postfix-spec-kwds, c-keywords, c-keywords-regexp, c-keywords-obarray,
c-nonlabel-token-key, and c-regular-keywords-regexp. It's easier and
more flexible to simply allow the entire set of c-lang-defconst values
to change. You also have to recompute the font-lock matchers, which is
similarly involved.

You claim that there is a great risk of negative side effects resulting
from this change. I don't agree, and I don't see anyone else proposing,
much less implementing, a solution to this problem, and cc-mode's being
developed outside the tree makes it frustratingly slow and difficult to
get much-needed fixes into core where users can see them.

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

It's not a massive change in architecture. cc-mode can already evaluate
these variables at runtime in the case of a version mismatch. I propose
simply doing so all the time. My timing indicates that it's not a
performance problem in practice.