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: Sun, 18 May 2014 21:33:31 +0000 [thread overview]
Message-ID: <20140518213331.GB2577@acm.acm> (raw)
In-Reply-To: <537653A0.2070109@dancol.org>
Hello, Daniel.
On Fri, May 16, 2014 at 11:06:24AM -0700, Daniel Colascione wrote:
> 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?
No I hadn't.
> 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.
OK. Then another alternative is to use `or' forms in the appropriate
places, of which there are several rather than many, the extra arm of
the `or' looking something like "(looking-at c-noise-macro-re)". Did you
consider this at all? If so, why do you prefer the solution you now
propose?
> It's easier and more flexible to simply allow the entire set of
> c-lang-defconst values to change.
It's the flexibility that worries me. Flexibility means complexity (of
which there's already too much in CC Mode), and might open up a larger
"attack surface" for future bugs.
I've spent a lot of time trying to pin down exactly what your proposed
change does and how it does it, but amn't there yet. I only have the
before and after versions, not a detailed description of the change.
> You also have to recompute the font-lock matchers, which is similarly
> involved.
Yes.
> You claim that there is a great risk of negative side effects resulting
> from this change.
No. I've said there is a risk, without quantifying it.
One question which you haven't addressed yet is does the changed code
work properly on modes derived from a CC Mode mode? How easy is it to
create a `foo-extra-keywords' for such a mode?
Another is does the change work properly under XEmacs?
What is the purpose of {java,idl,pike}-extra-keywords, given that these
three languages don't have #defines?
> I don't agree, and I don't see anyone else proposing, much less
> implementing, a solution to this problem, .....
:-) This problem was first highlighted as such, by you, this month, not
several years ago. Your patch is complicated, it's disruptive, yet you
seem put out that I want to discuss it and understand it, rather than
just blindly applying it as it is. It seems your use of "You need to"
and "we have to" weren't mere hyperbole as I first thought. Forgive me,
but I'm always suspicious when somebody tells me "there's no
alternative". There are always alternatives. The question is why is
your patch, which is not a straightforward or obvious change, the best
solution to the problem. What are the tradeoffs?
> .... 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.
Would it really be much faster if CC Mode were integrated? Not really.
What makes things slow is the small number of people working on CC Mode,
i.e. one, with occasional help from people like yourself.
> > 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.
As I said, I don't fully understand the change, yet. But moving
calculations from compile time to run time _is_ a change of
architecture, and it seems to me not to be small. It seems to me
that the rigid separation between language (e.g. C) and user
configuration is being broken down. How much easier will it be for a
user mistakenly to attempt to configure her CC Mode by messing around
with the c-lang-consts?
> cc-mode can already evaluate these variables at runtime in the case of
> a version mismatch.
That's a feature intended purely for CC Mode developers.
> I propose simply doing so all the time. My timing indicates that it's
> not a performance problem in practice.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2014-05-18 21:33 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
2014-05-16 17:52 ` Alan Mackenzie
2014-05-16 18:06 ` Daniel Colascione
2014-05-18 21:33 ` Alan Mackenzie [this message]
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=20140518213331.GB2577@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 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.