[PATCH] Add Microsoft support to cc-mode

[PATCH] Add Microsoft support to cc-mode

[Daniel Colascione]

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

bug#6959: [PATCH] Add Microsoft support to cc-mode

[Stefan Monnier]

[ 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

bug#6959: [PATCH] Add Microsoft support to cc-mode

[Daniel Colascione]

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

bug#6959: [PATCH] Add Microsoft support to cc-mode

[Stefan Monnier]

> 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

bug#6959: [PATCH] Add Microsoft support to cc-mode

[Lars Ingebrigtsen]

Daniel Colascione <dan.colascione@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

bug#6959: [PATCH] Add Microsoft support to cc-mode

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On 02/25/2016 10:42 PM, Lars Ingebrigtsen wrote:
> Daniel Colascione <dan.colascione@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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]