From: Alan Mackenzie <acm@muc.de>
To: Daniel Colascione <dancol@dancol.org>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: POC: customizable cc-mode keywords
Date: Fri, 16 May 2014 17:52:27 +0000 [thread overview]
Message-ID: <20140516175226.GB3267@acm.acm> (raw)
In-Reply-To: <536FEA43.5090402@dancol.org>
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).
next prev parent reply other threads:[~2014-05-16 17:52 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 5:26 POC: customizable cc-mode keywords Daniel Colascione
2014-05-10 23:13 ` Daniel Colascione
2014-05-11 21:13 ` Alan Mackenzie
2014-05-11 21:23 ` Daniel Colascione
2014-05-16 17:52 ` Alan Mackenzie [this message]
2014-05-16 18:06 ` Daniel Colascione
2014-05-18 21:33 ` Alan Mackenzie
2014-05-18 22:28 ` Daniel Colascione
2014-05-19 2:25 ` Stefan Monnier
2014-05-25 18:08 ` Alan Mackenzie
2014-09-08 17:28 ` Stefan Monnier
2014-09-11 13:55 ` Further CC-mode changes Stefan Monnier
2014-09-12 23:59 ` Alan Mackenzie
2014-09-13 1:09 ` Ivan Andrus
2014-09-13 10:04 ` Alan Mackenzie
2014-09-13 3:04 ` Stefan Monnier
2014-09-13 15:10 ` Alan Mackenzie
2014-09-13 19:24 ` Stefan Monnier
2014-09-13 23:08 ` Syntax-propertize and CC-mode [Was: Further CC-mode changes] Alan Mackenzie
2014-09-14 4:04 ` Stefan Monnier
2014-09-16 17:30 ` Sync'ing cc-mode Stefan Monnier
2014-09-26 19:19 ` Stefan Monnier
2014-09-15 20:24 ` Further CC-mode changes Glenn Morris
2014-09-16 3:07 ` Stephen J. Turnbull
2014-09-16 13:39 ` Stefan Monnier
2014-09-16 14:22 ` David Kastrup
2014-09-16 23:40 ` Stephen J. Turnbull
2014-09-17 1:02 ` Stefan Monnier
2014-09-17 1:48 ` Stephen J. Turnbull
2014-09-17 5:22 ` David Kastrup
2014-09-17 13:00 ` Stefan Monnier
2014-09-17 18:31 ` Glenn Morris
2014-09-17 19:12 ` David Kastrup
2014-09-17 5:24 ` Eli Zaretskii
2014-09-17 6:54 ` Stephen J. Turnbull
2014-09-17 7:20 ` Eli Zaretskii
2014-09-17 7:30 ` David Kastrup
2014-09-17 13:04 ` Stefan Monnier
2014-09-17 18:25 ` Glenn Morris
2014-09-18 5:20 ` Stephen J. Turnbull
2014-09-18 9:44 ` Emilio Lopes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140516175226.GB3267@acm.acm \
--to=acm@muc.de \
--cc=dancol@dancol.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).