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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6959 in the body.
You can then email your comments to 6959 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Daniel Colascione <dan.colascione <at> gmail.com>
To: emacs-devel <at> gnu.org, bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Add Microsoft support to cc-mode
Date: Tue, 31 Aug 2010 14:01:23 -0700

Microsoft uses a... unique programming style (erm, typedef void
VOID?!) that tends to trip up cc-mode. Particularly problematic are
certain code annotations, as described in
http://msdn.microsoft.com/en-us/library/aa383701(VS.85).aspx. This
patch adds support for this bizarre programming style and allows one
to work on idiomatic Windows sources comfortably.

You can get the diff at

http://bazaar.launchpad.net/~dan-colascione/emacs/c++0x/revision/101039

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Colascione <dan.colascione <at> gmail.com>
Cc: 6959 <at> debbugs.gnu.org
Subject: Re: [PATCH] Add Microsoft support to cc-mode
Date: Wed, 01 Sep 2010 08:38:50 +0200

[ Please don't send to both emacs-devel and bug-gnu-emacs, otherwise
every reply in emacs-devel risks generating a new bug-number. ]

> Microsoft uses a... unique programming style (erm, typedef void
> VOID?!) that tends to trip up cc-mode.

What do you mean by "trip up"?  Sounds like a plain bug to me: any
normal program may have such definitions (tho it depends on how "tripped
up" it gets; it's normal for cc-mode to behave suboptimally when
encountering unknown macros and type annotations, but it should try to
be robust in such circumstances).

> Particularly problematic are certain code annotations, as described in
> http://msdn.microsoft.com/en-us/library/aa383701(VS.85).aspx.  This
> patch adds support for this bizarre programming style and allows one
> to work on idiomatic Windows sources comfortably.

Similar needs arise for large projects (e.g. DEFUN and friends in
Emacs's C code), IIUC, right?

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.


        Stefan

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Colascione <dan.colascione <at> gmail.com>
Cc: 6959 <at> debbugs.gnu.org
Subject: Re: [PATCH] Add Microsoft support to cc-mode
Date: Fri, 14 Jan 2011 10:52:20 -0500

> I've just been using a private branch for cc-mode, but that's not an
> option for sane people. :-)

Hopefully by now, none of our users are still sane,


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Daniel Colascione <dan.colascione <at> gmail.com>
Cc: 6959 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#6959: [PATCH] Add Microsoft support to cc-mode
Date: Fri, 26 Feb 2016 17:12:42 +1030

Daniel Colascione <dan.colascione <at> gmail.com> writes:

> Microsoft uses a... unique programming style (erm, typedef void
> VOID?!) that tends to trip up cc-mode. Particularly problematic are
> certain code annotations, as described in
> http://msdn.microsoft.com/en-us/library/aa383701(VS.85).aspx. This
> patch adds support for this bizarre programming style and allows one
> to work on idiomatic Windows sources comfortably.
>
> You can get the diff at
>
> http://bazaar.launchpad.net/~dan-colascione/emacs/c++0x/revision/101039

Could you resend the patch (if this is still an issue)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Daniel Colascione <dan.colascione <at> gmail.com>
Cc: 6959 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#6959: [PATCH] Add Microsoft support to cc-mode
Date: Thu, 25 Feb 2016 22:44:45 -0800

[Message part 1 (text/plain, inline)]

On 02/25/2016 10:42 PM, Lars Ingebrigtsen wrote:
> Daniel Colascione <dan.colascione <at> gmail.com> writes:
> 
>> Microsoft uses a... unique programming style (erm, typedef void
>> VOID?!) that tends to trip up cc-mode. Particularly problematic are
>> certain code annotations, as described in
>> http://msdn.microsoft.com/en-us/library/aa383701(VS.85).aspx. This
>> patch adds support for this bizarre programming style and allows one
>> to work on idiomatic Windows sources comfortably.
>>
>> You can get the diff at
>>
>> http://bazaar.launchpad.net/~dan-colascione/emacs/c++0x/revision/101039
> 
> Could you resend the patch (if this is still an issue)?

It's not worth thinking about anymore. These days, I'd just define a
derived mode and be done with it. Besides, as I recall, performance
wasn't great with that patch.

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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