emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] support a few of the new features of C++11 in syntax highlig


From: Óscar Fuentes
Subject: Re: [PATCH] support a few of the new features of C++11 in syntax highlighting
Date: Tue, 18 Nov 2014 19:33:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Daniel Colascione <address@hidden> writes:

> Patch cc-engine to recognize the proper context if you care so much.
> Until you can do that, do not touch cc-mode.

Have you become the maintainer of c-mode overnight whithout anybody
noticing? No? Then, please abstain from commanding people about what
they can and cannot touch.

(BTW, I would never introduce a change on c-mode, Emacs or any project
in general without the maintainer(s) approval, if such change has the
most remote possibility of being controversial or risky.)

>>> They're not like "const" at all.
>> 
>> As far as c-mode is concerned, they are like "certain variety of const."
>
> No, lexically, they are completely different. You cannot have a
> variable called "const". You can have a variable called "final".

Yes, you made that clear on your previous message. But where the
"override/final" *specifiers* are expected, "const" is also legal. If
you mean that c-mode fontifies "const" on first sight because it makes
no distinctions between the multiple roles of "const", that's ok, then
we have no existing heuristics for detecting "override/final".

>> If c-mode uses the same heuristics everywhere for fontifying `const',
>> that means that we cannot exploit the existing mechanism for fontifying
>> "override" and "final". To bad. Then I would vote for adding them to
>> some list of keywords. As I said, not having them fontified when they
>> should is worse than having them fontified when they shouldn't.
>
> Do not introduce bugs into Emacs cc-mode. It's one of Emacs most
> widely used features and will not change to suit your non-universal
> preferences. If you want to err on the side of over-highlighting, you
> are free to create a derived mode locally.

<g>

> Do it right or not at all. 

C-mode is not doing right wrt "override/final". My *opinion* is that my
wrong is less wrong than your wrong.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]