[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: POC: customizable cc-mode keywords
From: |
Alan Mackenzie |
Subject: |
Re: POC: customizable cc-mode keywords |
Date: |
Fri, 16 May 2014 17:52:27 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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).
- POC: customizable cc-mode keywords, Daniel Colascione, 2014/05/02
- Re: POC: customizable cc-mode keywords, Daniel Colascione, 2014/05/10
- Re: POC: customizable cc-mode keywords, Alan Mackenzie, 2014/05/11
- Re: POC: customizable cc-mode keywords, Daniel Colascione, 2014/05/11
- Re: POC: customizable cc-mode keywords,
Alan Mackenzie <=
- Re: POC: customizable cc-mode keywords, Daniel Colascione, 2014/05/16
- Re: POC: customizable cc-mode keywords, Alan Mackenzie, 2014/05/18
- Re: POC: customizable cc-mode keywords, Daniel Colascione, 2014/05/18
- Re: POC: customizable cc-mode keywords, Stefan Monnier, 2014/05/18
- Re: POC: customizable cc-mode keywords, Alan Mackenzie, 2014/05/25