From: Daniel Colascione <dan.colascione@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 6959@debbugs.gnu.org
Subject: bug#6959: [PATCH] Add Microsoft support to cc-mode
Date: Thu, 13 Jan 2011 21:54:12 -0800 [thread overview]
Message-ID: <AANLkTikiyDD5YnYGbtWcNxhaA42OLTwRCjvVbkTFvdw=@mail.gmail.com> (raw)
In-Reply-To: <jwvoccic73r.fsf-monnier+emacs@gnu.org>
Hi Stefan,
On Tue, Aug 31, 2010 at 11:38 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> So I think we would want to move such project/system-specific outside
> cc-langs.el so users can (load "cc-microsoft") or (load "cc-linux") or
> (load "cc-emacs"). Tho, loading a file is the wrong interface, so maybe
> it can live in cc-langs.el but it should be inside a function so you
> could activate it with (cc-enable-microsoft-keywords), or maybe a minor
> mode (cc-microsoft-keywords-mode 1), tho turning it off might not be
> that important.
> The point is to make it modular so it's easy for people to add support
> for particular projects.
Unfortunately, cc-mode doesn't have a good mechanism for implementing
the kind of interface we'd both like. To do it, we have essentially
two choices:
1) Define a new, external cc-mode language for each optional package:
he problem with this approach is that the language structure is a
tree, so you can't easily combine multiple optional packages. Besides,
cc-engine.el and cc-fonts.el have many explicit tests for specific
languages (especially C++), and defining a language derived from C++
will make these tests fail. This is a separate bug, and one reason
very few people actually use the cc-mode external language support.
2) Allow c-lang-defconst values to be redefined by the user after
cc-mode is compiled: this would work fine, and would permit exactly
the kind of interface you propose. The main problem is that
c-lang-defconst values are baked into modes and their
font-lock-keywords values at compile time,though there's a special
case for c-extra-types. Fixing this deficiency would require the
entire cc-mode variable graph to be evaluated at mode initialization
time. On a modern machine, that shouldn't be a performance problem,
but the current macrology is subtle and quick to anger. I'm also not
quite sure what should happen when, for a variable c-foo, we have a
c-mode definition, a c++-mode definition that relies on the c-mode
value, and the user customizes the value for c-foo in c-mode. Do we
need to re-evaluate the value for c++-mode?
Integrating major language extensions directly into cc-mode is the
least general, but also the least invasive solution to the problem,
and there's already some precedent for QT. Until we get that generic
user-customizable, composable PEG-based mode support I've been
dreaming about, it's the best we can do.
I've just been using a private branch for cc-mode, but that's not an
option for sane people. :-)
Regards,
Daniel Colascione
next prev parent reply other threads:[~2011-01-14 5:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-31 21:01 [PATCH] Add Microsoft support to cc-mode Daniel Colascione
2010-09-01 6:38 ` bug#6959: " Stefan Monnier
[not found] ` <jwvoccic73r.fsf-monnier+emacs@gnu.org>
2011-01-14 5:54 ` Daniel Colascione [this message]
2011-01-14 15:52 ` Stefan Monnier
2016-02-26 6:42 ` Lars Ingebrigtsen
2016-02-26 6:42 ` Lars Ingebrigtsen
2016-02-26 6:44 ` Daniel Colascione
2016-02-26 6:44 ` Daniel Colascione
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='AANLkTikiyDD5YnYGbtWcNxhaA42OLTwRCjvVbkTFvdw=@mail.gmail.com' \
--to=dan.colascione@gmail.com \
--cc=6959@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.