GNU bug report logs - #6959
[PATCH] Add Microsoft support to cc-mode

Previous Next

Full log

Message #11 received at 6959 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dan.colascione <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6959 <at> debbugs.gnu.org
Subject: Re: [PATCH] Add Microsoft support to cc-mode
Date: Thu, 13 Jan 2011 21:54:12 -0800

Hi Stefan,

On Tue, Aug 31, 2010 at 11:38 PM, Stefan Monnier
<monnier <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.