From: Daniel Colascione <dancol@dancol.org>
To: Alan Mackenzie <acm@muc.de>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: POC: customizable cc-mode keywords
Date: Sun, 11 May 2014 14:23:15 -0700 [thread overview]
Message-ID: <536FEA43.5090402@dancol.org> (raw)
In-Reply-To: <20140511211351.GC2759@acm.acm>
[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]
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.
>> 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.
What's your alternative?
> 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.
They're public either way.
>> 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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
next prev parent reply other threads:[~2014-05-11 21:23 UTC|newest]
Thread overview: 42+ 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 [this message]
2014-05-16 17:52 ` Alan Mackenzie
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
[not found] ` <jwv4mvmjl0c.fsf-monnier+emacs@gnu.org>
[not found] ` <jwv4mvkqy4g.fsf-monnier+emacs@gnu.org>
[not found] ` <jwv4mv3mn2a.fsf-monnier+emacs@gnu.org>
[not found] ` <jwv38a644p7.fsf-monnier+emacs@gnu.org>
[not found] ` <jwvppd2wx7o.fsf-monnier+emacs@gnu.org>
[not found] ` <20141106104534.GA3385@acm.acm>
2014-11-06 14:06 ` bug#18022: " 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=536FEA43.5090402@dancol.org \
--to=dancol@dancol.org \
--cc=acm@muc.de \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.