[PATCH] support a few of the new features of C++11 in syntax highlighting

[PATCH] support a few of the new features of C++11 in syntax highlighting

[Paul Pogonyshev]

[-- Attachment #1.1: Type: text/plain, Size: 690 bytes --]

This patch adds support for a few of new C++11 features. I added only the
ones easy to implement (basically, just adding keywords to lists), since
I'm not familiar with the way cc-mode works. Hope this patch is not
controversial. I submitted required legal papers years ago, you can find a
few my patches in ChangeLog.

Paul


2014-01-25  Paul Pogonyshev  <pogonyshev@gmail.com>

    * progmodes/cc-langs.el: Support some of the new keywords in
    C++11.
    (c-operators): Handle `alignof' and `decltype'.
    (c-primitive-type-kwds): Add `char16_t' and `char32_t' primitive
    types.
    (c-type-modifier-kwds): Add `constexpr' and `thread_local'.
    (c-constant-kwds): Add `nullptr'.

[-- Attachment #1.2: Type: text/html, Size: 877 bytes --]

[-- Attachment #2: c++11.diff --]
[-- Type: text/plain, Size: 1987 bytes --]

diff --git a/lisp/progmodes/cc-langs.el b/lisp/progmodes/cc-langs.el
index 29dff4a..cadbe2f 100644
--- a/lisp/progmodes/cc-langs.el
+++ b/lisp/progmodes/cc-langs.el
@@ -973,7 +973,7 @@ since CC Mode treats every identifier as an expression."
 
       ;; Unary.
       (prefix "++" "--" "+" "-" "!" "~"
-	      ,@(when (c-major-mode-is 'c++-mode) '("not" "compl"))
+	      ,@(when (c-major-mode-is 'c++-mode) '("not" "compl" "alignof" "decltype"))
 	      ,@(when (c-major-mode-is '(c-mode c++-mode))
 		  '("*" "&" "sizeof" "??-"))
 	      ,@(when (c-major-mode-is 'objc-mode)
@@ -1606,7 +1606,7 @@ the appropriate place for that."
 	'("_Bool" "_Complex" "_Imaginary") ; Conditionally defined in C99.
 	(c-lang-const c-primitive-type-kwds))
   c++  (append
-	'("bool" "wchar_t")
+	'("bool" "wchar_t" "char16_t" "char32_t")
 	(c-lang-const c-primitive-type-kwds))
   ;; Objective-C extends C, but probably not the new stuff in C99.
   objc (append
@@ -1676,7 +1676,7 @@ but they don't build a type of themselves.  Unlike the keywords on
 not the type face."
   t    nil
   c    '("const" "restrict" "volatile")
-  c++  '("const" "volatile" "throw")
+  c++  '("const" "constexpr" "volatile" "throw" "thread_local")
   objc '("const" "volatile"))
 
 (c-lang-defconst c-opt-type-modifier-key
@@ -2308,8 +2308,12 @@ This construct is \"<keyword> <expression> :\"."
 (c-lang-defconst c-constant-kwds
   "Keywords for constants."
   t       nil
-  (c c++) '("NULL" ;; Not a keyword, but practically works as one.
+  c       '("NULL" ;; Not a keyword, but practically works as one.
 	    "false" "true")		; Defined in C99.
+  c++     '("NULL" ;; Not a keyword, but practically works as one. Kept for
+                   ;; older code that doesn't use C++11's nullptr.
+	    "false" "true"
+            "nullptr")
   objc    '("nil" "Nil" "YES" "NO" "NS_DURING" "NS_HANDLER" "NS_ENDHANDLER")
   idl     '("TRUE" "FALSE")
   java    '("true" "false" "null") ; technically "literals", not keywords

[-- Attachment #3: changelog-entry --]
[-- Type: application/octet-stream, Size: 342 bytes --]

2014-01-25  Paul Pogonyshev  <pogonyshev@gmail.com>

	* progmodes/cc-langs.el: Support some of the new keywords in
	C++11.
	(c-operators): Handle `alignof' and `decltype'.
	(c-primitive-type-kwds): Add `char16_t' and `char32_t' primitive
	types.
	(c-type-modifier-kwds): Add `constexpr' and `thread_local'.
	(c-constant-kwds): Add `nullptr'.

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

[Glenn Morris]

I would advise you to send this to the bug list.
Although a similar (?) patch has been there for a year.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13871

So maybe send it as followup to that if it seems appropriate to you.

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

[Stefan Monnier]

> I would advise you to send this to the bug list.
> Although a similar (?) patch has been there for a year.
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13871
> So maybe send it as followup to that if it seems appropriate to you.

Agreed.  Of course, we can't install this right now since we're in
feature freeze, but if someone could deal with this soon after we re-open
the trunk, that would be helpful,


        Stefan

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

[Daniel Colascione]

On 01/25/2014 01:56 PM, Stefan Monnier wrote:
>> I would advise you to send this to the bug list.
>> Although a similar (?) patch has been there for a year.
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13871
>> So maybe send it as followup to that if it seems appropriate to you.
>
> Agreed.  Of course, we can't install this right now since we're in
> feature freeze, but if someone could deal with this soon after we re-open
> the trunk, that would be helpful,

I have a much older C++11 (from back when it was called C++0x) patch (it 
should be in the archives somewhere) that supports "auto", attributes, 
the ">>" template-closing syntax, and a few of C++'s contextual 
keywords, like "override". I should update it after the feature freeze. 
A big challenge is making uniform initialization work properly; I'd love 
Alan's thoughts on the best way to approach that subject. I think we 
also need a new indentation type for lambdas.

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

[Glenn Morris]

Daniel Colascione wrote:

> I have a much older C++11 (from back when it was called C++0x) patch
> (it should be in the archives somewhere) that supports "auto",

Maybe http://debbugs.gnu.org/5457

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

[Daniel Colascione]

On 01/25/2014 04:27 PM, Glenn Morris wrote:
> Daniel Colascione wrote:
>
>> I have a much older C++11 (from back when it was called C++0x) patch
>> (it should be in the archives somewhere) that supports "auto",
>
> Maybe http://debbugs.gnu.org/5457

That's the one. Thanks for digging it up.

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

[Alan Mackenzie]

Hello, all.

On Sat, Jan 25, 2014 at 02:34:37PM -0800, Daniel Colascione wrote:
> On 01/25/2014 01:56 PM, Stefan Monnier wrote:
> >> I would advise you to send this to the bug list.
> >> Although a similar (?) patch has been there for a year.
> >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13871
> >> So maybe send it as followup to that if it seems appropriate to you.

> > Agreed.  Of course, we can't install this right now since we're in
> > feature freeze, but if someone could deal with this soon after we re-open
> > the trunk, that would be helpful,

> I have a much older C++11 (from back when it was called C++0x) patch (it 
> should be in the archives somewhere) that supports "auto", attributes, 
> the ">>" template-closing syntax, and a few of C++'s contextual 
> keywords, like "override". I should update it after the feature freeze. 
> A big challenge is making uniform initialization work properly; I'd love 
> Alan's thoughts on the best way to approach that subject. I think we 
> also need a new indentation type for lambdas.

I've had enhancements for some C++11 features integrated into CC Mode at
SourceForge for some while, but I haven't yet pushed them to the
repository there (with one exception).

These features are:
(i) ">>" as double template ender (already at SourceForge);
(ii) "auto foo = <expression>;";
(iii) "decltype (foo)" as a type;
(iv) "auto foo (<args>) -> <type> { ..... }".

Daniel, in the end I didn't use the code in your patch, though the test
file was handy indeed.

I'd been hoping to implement more C++11 features before releasing all
the above, but I'm not getting much done.  I don't have enough time to
spend on CC Mode, and I'm largely bogged down with bug fixes at the
moment.  If somebody were willing to spend the time to learn how CC Mode
works, then implement more of C++11's features, I'd be most grateful for
the help.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Václav Zeman]

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

On 25.1.2014 13:51, Paul Pogonyshev wrote:
> This patch adds support for a few of new C++11 features. I added only
> the ones easy to implement (basically, just adding keywords to lists),
> since I'm not familiar with the way cc-mode works. Hope this patch is
> not controversial. I submitted required legal papers years ago, you can
> find a few my patches in ChangeLog.
> 
> Paul
> 
> 
> 2014-01-25  Paul Pogonyshev  <pogonyshev@gmail.com
> <mailto:pogonyshev@gmail.com>>
> 
>     * progmodes/cc-langs.el: Support some of the new keywords in
>     C++11.
>     (c-operators): Handle `alignof' and `decltype'.
>     (c-primitive-type-kwds): Add `char16_t' and `char32_t' primitive
>     types.
>     (c-type-modifier-kwds): Add `constexpr' and `thread_local'.
>     (c-constant-kwds): Add `nullptr'.
> 

Has this thread come to any conclusion? Were your collective patches
merged and committed?

-- 
VZ



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

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

[Óscar Fuentes]

Václav Zeman <vhaisman@gmail.com> writes:

> On 25.1.2014 13:51, Paul Pogonyshev wrote:
>> This patch adds support for a few of new C++11 features. I added only
>> the ones easy to implement (basically, just adding keywords to lists),
>> since I'm not familiar with the way cc-mode works. Hope this patch is
>> not controversial. I submitted required legal papers years ago, you can
>> find a few my patches in ChangeLog.
>> 
>> Paul
>> 
>> 
>> 2014-01-25  Paul Pogonyshev  <pogonyshev@gmail.com
>> <mailto:pogonyshev@gmail.com>>
>> 
>>     * progmodes/cc-langs.el: Support some of the new keywords in
>>     C++11.
>>     (c-operators): Handle `alignof' and `decltype'.
>>     (c-primitive-type-kwds): Add `char16_t' and `char32_t' primitive
>>     types.
>>     (c-type-modifier-kwds): Add `constexpr' and `thread_local'.
>>     (c-constant-kwds): Add `nullptr'.
>> 
>
> Has this thread come to any conclusion? Were your collective patches
> merged and committed?

No. Most likely it was unnoticed by Alan.

Patches should be sent to the bug database to prevent them from
disappearing from the maintainer's radar.

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

[Glenn Morris]

Óscar Fuentes wrote:

> No. Most likely it was unnoticed by Alan.

?

http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02104.html

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

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> Óscar Fuentes wrote:
>
>> No. Most likely it was unnoticed by Alan.
>
> ?
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02104.html

So Alan noticed the patch, but the "no" still stands: the patch was not
merged and there was no conclusion about it (except for Alan saying that
he already implemented on the SF cc-mode some of the features mentioned
on the patch and that he has no time for merging those changes into
Emacs.)

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

[Alan Mackenzie]

Hello, Óscar.

On Sun, May 11, 2014 at 10:19:49PM +0200, Óscar Fuentes wrote:
> Glenn Morris <rgm@gnu.org> writes:

> > Óscar Fuentes wrote:

> >> No. Most likely it was unnoticed by Alan.

> > ?

> > http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02104.html

> So Alan noticed the patch, but the "no" still stands: the patch was not
> merged and there was no conclusion about it (except for Alan saying that
> he already implemented on the SF cc-mode some of the features mentioned
> on the patch and that he has no time for merging those changes into
> Emacs.)

These features are available in the c++11-0-1 branch of the CC Mode
repository at http://hg.code.sf.net/p/cc-mode/cc-mode, best downloaded by
prefixing the address with 'hg clone ', and appending it with a new
directory name.

As already stated, help in implementing further C++11 features would be
welcome.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

>> So Alan noticed the patch, but the "no" still stands: the patch was not
>> merged and there was no conclusion about it (except for Alan saying that
>> he already implemented on the SF cc-mode some of the features mentioned
>> on the patch and that he has no time for merging those changes into
>> Emacs.)
>
> These features are available in the c++11-0-1 branch of the CC Mode
> repository at http://hg.code.sf.net/p/cc-mode/cc-mode, best downloaded by
> prefixing the address with 'hg clone ', and appending it with a new
> directory name.
>
> As already stated, help in implementing further C++11 features would be
> welcome.

I would be more interested on helping to incorporate into Emacs the
features already implemented on the SF repository.

What can I do about that?

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

[Alan Mackenzie]

Hello, Óscar.

On Mon, May 12, 2014 at 12:38:41AM +0200, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> So Alan noticed the patch, but the "no" still stands: the patch was not
> >> merged and there was no conclusion about it (except for Alan saying that
> >> he already implemented on the SF cc-mode some of the features mentioned
> >> on the patch and that he has no time for merging those changes into
> >> Emacs.)

> > These features are available in the c++11-0-1 branch of the CC Mode
> > repository at http://hg.code.sf.net/p/cc-mode/cc-mode, best downloaded by
> > prefixing the address with 'hg clone ', and appending it with a new
> > directory name.

> > As already stated, help in implementing further C++11 features would be
> > welcome.

> I would be more interested on helping to incorporate into Emacs the
> features already implemented on the SF repository.

> What can I do about that?

OK.  I suggest proceeding as follows.  First download the CC Mode
(Mercurial) repository, as detailed above.  Then get the diff between the
"default" branch (i.e. the trunk) and the c++11-0-1 branch for the files
cc-*.el:

    hg diff -r default:c++11-0-1 cc-*.el > foo.diff

.  Then (the hard part), disregarding the irrelevant diff hunks in that
file (e.g. changes in the copyright statement), apply the diffs to the
CC Mode files in the Emacs trunk.  This will likely involve a fair bit of
hand editing.  Please do this job very carefully - it would be a
knightmare to untangle if you were to make mistakes here.

Before committing this it would be best to test it using the regression
test suite in the directory ...../tests.  See the comments in the file
..../tests/000tests.el for instructions.  You'll need to move the entire
..../tests directory to under ..../lisp/progmodes (or set up appropriate
symbolic links) for this to work.

As a commit message, could you copy them from the CC Mode repository,
please.  All the commits in the c++-11-0-1 branch can be got reasonably
with:

    hg -v log -X .hgtags -b c++11-0-1

.  All the commits in default can similarly be got with

    hg -v log -X .hgtags -b default

.  Whatever changes are in c++-11-0-1 which aren't in default are the new
C++11 features.  They should form the basis of your commit message.

If you need any help, just email me.

Good luck!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

[snip]

> Good luck!

Thanks Alan for the detailed instructions. I'll try to look into this on
the next few days.

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

[Stefan Monnier]

>> What can I do about that?
> OK.  I suggest proceeding as follows.

I'm curious: how did we get to this point?
Shouldn't such development take place on trunk, or a branch that's
regularly sync'd with Emacs's trunk?


        Stefan

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

[Alan Mackenzie]

Hi, Stefan.

On Wed, May 14, 2014 at 09:52:30PM -0400, Stefan Monnier wrote:
> >> What can I do about that?
> > OK.  I suggest proceeding as follows.

> I'm curious: how did we get to this point?

We've never been anywhere else.  CC Mode developement has always taken
place mainly in its own project at SourceForge.  Just that some years
ago, I started feeding bug fixes through to Emacs (and XEmacs)
immediately, rather than waiting for the next CC Mode release.

> Shouldn't such development take place on trunk, or a branch that's
> regularly sync'd with Emacs's trunk?

Absolutely not.  That would risk having incoherent code automatically
transferred to Emacs.  Anyhow, stand alone CC Mode and that in Emacs
have drifted apart to the extent that any such synching would usually
need manual effort (as Óscar will likely find out).  Reducing those
differences is on my todo list.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 16 May 2014 16:07:43 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> > I'm curious: how did we get to this point?
> 
> We've never been anywhere else.  CC Mode developement has always taken
> place mainly in its own project at SourceForge.

Then I guess the question is "why keep doing that?"  IOW, why not
develop it as part of Emacs?

> > Shouldn't such development take place on trunk, or a branch that's
> > regularly sync'd with Emacs's trunk?
> 
> Absolutely not.  That would risk having incoherent code automatically
> transferred to Emacs.

You can always use a public branch as part of the Emacs repository,
"cc-mode-unstable", say, and merge from it to trunk when you see fit.
Then this issue won't exist.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, May 16, 2014 at 08:59:20PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 16 May 2014 16:07:43 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org

> > > I'm curious: how did we get to this point?

> > We've never been anywhere else.  CC Mode developement has always taken
> > place mainly in its own project at SourceForge.

> Then I guess the question is "why keep doing that?"  IOW, why not
> develop it as part of Emacs?

CC Mode also feeds into XEmacs.  This would be more difficult to do if CC
Mode were an integrated part of Emacs rather than being independent of
both.

There are distinct advantages with working with a small code base on a
stable base (a released version of Emacs) as compared with being in the
thick of a "major war" (an upcoming version of Emacs, which doesn't even
build all the time).

Presumably other upstream projects like Gnus, Cedet, are distinct from
Emacs for similar reasons.

> > > Shouldn't such development take place on trunk, or a branch that's
> > > regularly sync'd with Emacs's trunk?

> > Absolutely not.  That would risk having incoherent code automatically
> > transferred to Emacs.

> You can always use a public branch as part of the Emacs repository,
> "cc-mode-unstable", say, and merge from it to trunk when you see fit.
> Then this issue won't exist.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 17 May 2014 08:31:10 +0000
> Cc: ofv@wanadoo.es, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Then I guess the question is "why keep doing that?"  IOW, why not
> > develop it as part of Emacs?
> 
> CC Mode also feeds into XEmacs.  This would be more difficult to do if CC
> Mode were an integrated part of Emacs rather than being independent of
> both.

I don't see how would this be more difficult.  In both cases, one must
checkout a foreign branch and integrate it into the tree.

> There are distinct advantages with working with a small code base on a
> stable base (a released version of Emacs) as compared with being in the
> thick of a "major war" (an upcoming version of Emacs, which doesn't even
> build all the time).

See my proposal to use a separate public branch within the Emacs
repository, which takes care of all this.

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Then I guess the question is "why keep doing that?"  IOW, why not
>> > develop it as part of Emacs?
>> 
>> CC Mode also feeds into XEmacs.  This would be more difficult to do if CC
>> Mode were an integrated part of Emacs rather than being independent of
>> both.
>
> I don't see how would this be more difficult.  In both cases, one must
> checkout a foreign branch and integrate it into the tree.

Technically spoken, you're right. But it might be difficult to request
from an XEmacs user to checkout code from the GNU Emacs repository in
order to test the very recent patches.

Furthermore, there might be files which are dedicated to XEmacs only,
and not for GNU Emacs. This is the case at least for Tramp.

And contributions from XEmacs users would also be less frequent (not
that there are so many in the Tramp case :-(

Best regards, Michael.

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

[Stefan Monnier]

> Technically spoken, you're right.  But it might be difficult to request
> from an XEmacs user to checkout code from the GNU Emacs repository in
> order to test the very recent patches.

The issue is not whether there's an external repository.  The issue is
about having a separate branch that evolves separately such that it ends
up drifting apart.

Gnus is a good example: they have an external branch (or even several),
but that external branch and the code in Emacs are constantly kept in
sync, so they don't need to worry about finding an Óscar to port some
new feature to the other branch: they can ask "git/bzr merge" to do that
job instead.


        Stefan

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

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The issue is not whether there's an external repository.  The issue is
> about having a separate branch that evolves separately such that it ends
> up drifting apart.
>
> Gnus is a good example: they have an external branch (or even several),
> but that external branch and the code in Emacs are constantly kept in
> sync, so they don't need to worry about finding an Óscar to port some
> new feature to the other branch: they can ask "git/bzr merge" to do that
> job instead.

That's how also org and Tramp do. At the very end, I've found that this
is the least effort (speaking for Tramp).

>         Stefan

Best regards, Michael.

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

[Stefan Monnier]

> That's how also org and Tramp do. At the very end, I've found that this
> is the least effort (speaking for Tramp).

Exactly.  But the key is to keep them in sync all the time.


        Stefan

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Then I guess the question is "why keep doing that?"  IOW, why not
>> > develop it as part of Emacs?
>> 
>> CC Mode also feeds into XEmacs.  This would be more difficult to do if CC
>> Mode were an integrated part of Emacs rather than being independent of
>> both.
>
> I don't see how would this be more difficult.  In both cases, one must
> checkout a foreign branch and integrate it into the tree.
>
>> There are distinct advantages with working with a small code base on a
>> stable base (a released version of Emacs) as compared with being in the
>> thick of a "major war" (an upcoming version of Emacs, which doesn't even
>> build all the time).
>
> See my proposal to use a separate public branch within the Emacs
> repository, which takes care of all this.

The major advantage of maintaining cc-mode on a Emacs branch would be to
easily (trivially?) re-create the history of the changes on cc-mode when
those are merged into Emacs. So from the point of view of those of us
that always work with the cc-mode integrated on the latest Emacs, it
would be the obvious workflow. But for those users and contributors with
older Emacs versions, working with/on the latest cc-mode version would
be more inconvenient. Alan would be inconvenienced too as he has to
develop/test cc-mode against multiple Emacs versions.

So I guess that merging cc-mode into Emacs (a specific branch of Emacs,
to be precise) would become very easy, but all the rest would be more
inconvenient, as long as the cc-mode development cares about past Emacs
versions.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 17 May 2014 15:27:19 +0200
> 
> from the point of view of those of us that always work with the
> cc-mode integrated on the latest Emacs, it would be the obvious
> workflow. But for those users and contributors with older Emacs
> versions, working with/on the latest cc-mode version would be more
> inconvenient. Alan would be inconvenienced too as he has to
> develop/test cc-mode against multiple Emacs versions.
> 
> So I guess that merging cc-mode into Emacs (a specific branch of Emacs,
> to be precise) would become very easy, but all the rest would be more
> inconvenient, as long as the cc-mode development cares about past Emacs
> versions.

I obviously won't pursue this any longer, as Alan sounds very much set
on his current arrangements.  But I cannot help wondering how real are
all those considerations you mentioned, given that major CC Mode
releases are relatively infrequent, on par with those of Emacs.  IMO,
both separate unsynchronized development and trying to cater to older
Emacs versions only make sense if a package is being released much
more frequently than the Emacs core.  Otherwise, it's pure overhead
and waste of valuable resources, since in practice no one has any good
reasons to use a newer CC Mode with an old Emacs.

The same goes for Gnus, FWIW (which AFAICS no longer provides its own
stable releases anyway), which Alan mentioned as another package with
similar mode of development.

Now, I'm sure a plethora of arguments will follow that would "explain"
why bringing all development to a single repo is not TRT, from the POV
of the developers of the corresponding packages.  But I'm also quite
sure all these arguments are not serious enough to justify the
terrible waste of time and energy we as a community suffer as the
result of these schisms.

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

[Stefan Monnier]

>> >> What can I do about that?
>> > OK.  I suggest proceeding as follows.
>> I'm curious: how did we get to this point?
> We've never been anywhere else.  CC Mode developement has always taken
> place mainly in its own project at SourceForge.

Right, this is not the part that bothers me.

> Anyhow, stand alone CC Mode and that in Emacs have drifted apart to
> the extent that any such synching would usually need manual effort (as
> Óscar will likely find out).

That's the first part that worries me.

The second is that this new C++11 branch seems to be based on the
standalone branch rather than the Emacs branch.

Am I reading too much into it or do you consider the standalone branch
as "the main branch"?


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > We've never been anywhere else.  CC Mode developement has always taken
    > place mainly in its own project at SourceForge.

    Right, this is not the part that bothers me.

The developer of CC Mode insisted on doing this even though
I told him it was likely to cause trouble.

I hope that the person doing this C++ work will adapt it to fit into
the code in the Emacs release.  Otherwise it won't reach most Emacs
users, and we will need to find someone to redo the work.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Alan Mackenzie]

Hi, Richard.

On Sat, May 17, 2014 at 12:17:57AM -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>     > We've never been anywhere else.  CC Mode developement has always taken
>     > place mainly in its own project at SourceForge.

>     Right, this is not the part that bothers me.

> The developer of CC Mode insisted on doing this even though
> I told him it was likely to cause trouble.

Presumably Barry Warsaw.  At the time (1992), I'm pretty sure he was
an XEmacs user, so would naturally want to support that platform too.

> I hope that the person doing this C++ work will adapt it to fit into
> the code in the Emacs release.  Otherwise it won't reach most Emacs
> users, and we will need to find someone to redo the work.

This is precisely his aim.  The amount of adaptation needed is minimal.
Standalone CC Mode runs without modification on Emacs.

> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    This is precisely his aim.  The amount of adaptation needed is minimal.
    Standalone CC Mode runs without modification on Emacs.

Few Emacs users will run Standalone CC Mode.  If this is to reach most
Emacs users, it needs to get merged into Emacs.  If the adaptation
needed is minimal, I hope someone does it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Barry Warsaw]

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

On May 17, 2014, at 09:03 AM, Alan Mackenzie wrote:

>Presumably Barry Warsaw.  At the time (1992), I'm pretty sure he was
>an XEmacs user, so would naturally want to support that platform too.

Gosh, 22 years is ancient history.  I think this was even before the XEmacs
name.  It was probably still called Lucid Emacs!  Back then, SourceForge
seemed like the best public code hosting site available.  I don't remember,
but we might have even used CVS at the time. ;)

I switched back to GNU Emacs in 2008.

That's not to say that XEmacs support should be dropped.  I personally don't
care about it much any more, but other people do, and I think we should
respect the current CC Mode maintainer's opinion on matters like this.

Cheers,
-Barry

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

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

[Alan Mackenzie]

Hello, Stefan.

On Fri, May 16, 2014 at 07:42:19PM -0400, Stefan Monnier wrote:
> >> >> What can I do about that?
> >> > OK.  I suggest proceeding as follows.
> >> I'm curious: how did we get to this point?
> > We've never been anywhere else.  CC Mode developement has always taken
> > place mainly in its own project at SourceForge.

> Right, this is not the part that bothers me.

> > Anyhow, stand alone CC Mode and that in Emacs have drifted apart to
> > the extent that any such synching would usually need manual effort (as
> > Óscar will likely find out).

> That's the first part that worries me.

Why?

> The second is that this new C++11 branch seems to be based on the
> standalone branch rather than the Emacs branch.

Yes.  But these changes for C++11 are at the "engine" level, which is
pretty much the same.  There are lots of typographical differences
though (like reformatted comments, spelling corrections, minor stylistic
changes) which throw off the patching.

> Am I reading too much into it or do you consider the standalone branch
> as "the main branch"?

I consider the standalone branch as the main one, yes.  That's the way
the project's been since longer than I've been involved with it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

>> > Anyhow, stand alone CC Mode and that in Emacs have drifted apart to
>> > the extent that any such synching would usually need manual effort (as
>> > Óscar will likely find out).
>> That's the first part that worries me.
> Why?

Not sure how to say it: when two branches drift apart, you tend to get
into trouble, you know like Emacs-vs-XEmacs, or "could someone spend
time porting the C++11 support to the other branch".

To tell you the truth, I don't even know why the two distributions can't
use the exact same code.  I.e. why did the two branches drift apart?

> There are lots of typographical differences though (like reformatted
> comments, spelling corrections, minor stylistic changes) which throw
> off the patching.

So the "drift" is about cosmetic details?  Why?  Sounds like masochism
to me.


        Stefan

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

[Rüdiger Sonderfeld]

Hi,

On Sunday 11 May 2014 22:09:47 Alan Mackenzie wrote:
> These features are available in the c++11-0-1 branch of the CC Mode
> repository at http://hg.code.sf.net/p/cc-mode/cc-mode, best downloaded by
> prefixing the address with 'hg clone ', and appending it with a new
> directory name.
> 
> As already stated, help in implementing further C++11 features would be
> welcome.

is there a time plan for merging the branch into Emacs?  Right now I think the 
situation is a bit frustrating and confusing.  Basic C++11 support is not 
working in branch Emacs, except for the "enum class" support that got merged 
in directly.  There are several patches for syntax highlight, but that's 
supposed to work in your branch already.  However merging the cc-mode branch 
into Emacs is, if I understand your description right, not straight forward 
and requires extra work.

How stable is the c++11 branch?  Now that 24.4 has shipped, couldn't it be 
merged?  I think that would open it up to far more contributors and testers 
than keeping it in a separate project.

Regards,
Rüdiger

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

[Óscar Fuentes]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> Hi,
>
> On Sunday 11 May 2014 22:09:47 Alan Mackenzie wrote:
>> These features are available in the c++11-0-1 branch of the CC Mode
>> repository at http://hg.code.sf.net/p/cc-mode/cc-mode, best downloaded by
>> prefixing the address with 'hg clone ', and appending it with a new
>> directory name.
>> 
>> As already stated, help in implementing further C++11 features would be
>> welcome.
>
> is there a time plan for merging the branch into Emacs?

What was available in Alan's cc-mode c++11 branch was merged long time
ago (it was mostly about decltype and auto, IIRC.)

It would be nice to apply the patch that started this thread, plus a few
other keywords. However, I had no opportunity of testing the adapted
patch because I did no C++ coding lately. No doubt someone which is
fluent on Emacs' syntax highlighting system could be able to assert the
validity of the patch without testing.

[snip]

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

[Rüdiger Sonderfeld]

On Sunday 16 November 2014 19:07:24 Óscar Fuentes wrote:
> What was available in Alan's cc-mode c++11 branch was merged long time
> ago (it was mostly about decltype and auto, IIRC.)
> 
> It would be nice to apply the patch that started this thread, plus a few
> other keywords. However, I had no opportunity of testing the adapted
> patch because I did no C++ coding lately. No doubt someone which is
> fluent on Emacs' syntax highlighting system could be able to assert the
> validity of the patch without testing.

I took the liberty to merge the patch.  I've updated and adjusted it a bit.

The "alignof" keyword is the only one still missing.  It seems that some 
extensions to cc-mode might be necessary to include it.

There is also this patch pending.  But it requires some more work: 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5457

Regards,
Rüdiger

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

[Óscar Fuentes]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> I took the liberty to merge the patch. I've updated and adjusted it a
> bit.

Thanks.

> The "alignof" keyword is the only one still missing.

From the top of my head: override is also missing.

[snip]

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

[Daniel Colascione]

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

On 11/17/2014 07:30 PM, Óscar Fuentes wrote:
> Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:
> 
>> I took the liberty to merge the patch. I've updated and adjusted it a
>> bit.
> 
> Thanks.
> 
>> The "alignof" keyword is the only one still missing.
> 
> From the top of my head: override is also missing.
> 

Because "override" (and "final") are keywords only in certain semantic contexts, supporting them requires special care.


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

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

[Óscar Fuentes]

Daniel Colascione <dancol@dancol.org> writes:

>>> The "alignof" keyword is the only one still missing.
>> 
>> From the top of my head: override is also missing.
>> 
>
> Because "override" (and "final") are keywords only in certain semantic
> contexts, supporting them requires special care.

override and final have the same context as `const' for methods, so we
could take that as a model. Skimming over cc-langs.el didn't show an
obvious place for it, though.

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

[Rüdiger Sonderfeld]

On Tuesday 18 November 2014 15:47:43 Óscar Fuentes wrote:
> Daniel Colascione <dancol@dancol.org> writes:
> >>> The "alignof" keyword is the only one still missing.
> >> 
> >> From the top of my head: override is also missing.
> > 
> > Because "override" (and "final") are keywords only in certain semantic
> > contexts, supporting them requires special care.
> 
> override and final have the same context as `const' for methods, so we
> could take that as a model. Skimming over cc-langs.el didn't show an
> obvious place for it, though.

Yes, but "const" has a meaning in other places as well.  That's why it is 
dealt with in `c-type-modifier-kwds'.  I think the problem is similar for 
"noexcept".  I've simply added it to `c-type-modifier-kwds' for now.  But it's 
actually the wrong place.  However unlike "override" and "final", there is 
also an operator version of "noexcept".

Regards,
Rüdiger

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

[Daniel Colascione]

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

On 11/18/2014 08:36 AM, Rüdiger Sonderfeld wrote:
> On Tuesday 18 November 2014 15:47:43 Óscar Fuentes wrote:
>> Daniel Colascione <dancol@dancol.org> writes:
>>>>> The "alignof" keyword is the only one still missing.
>>>>
>>>> From the top of my head: override is also missing.
>>>
>>> Because "override" (and "final") are keywords only in certain semantic
>>> contexts, supporting them requires special care.
>>
>> override and final have the same context as `const' for methods, so we
>> could take that as a model. Skimming over cc-langs.el didn't show an
>> obvious place for it, though.
> 
> Yes, but "const" has a meaning in other places as well.  That's why it is 
> dealt with in `c-type-modifier-kwds'.  I think the problem is similar for 
> "noexcept".  I've simply added it to `c-type-modifier-kwds' for now.  But it's 
> actually the wrong place.  However unlike "override" and "final", there is 
> also an operator version of "noexcept".

C++11 introduced the noexcept and constexpr keywords. They're always keywords. "override" and "final" are different. Please don't go hack those into cc-engine. Better to leave them unfontified than to fontify perfectly good identifiers as keywords. They're not like "const" at all.


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

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

[Óscar Fuentes]

Daniel Colascione <dancol@dancol.org> writes:

> On 11/18/2014 08:36 AM, Rüdiger Sonderfeld wrote:
>> On Tuesday 18 November 2014 15:47:43 Óscar Fuentes wrote:
>>> Daniel Colascione <dancol@dancol.org> writes:
>>>>>> The "alignof" keyword is the only one still missing.
>>>>>
>>>>> From the top of my head: override is also missing.
>>>>
>>>> Because "override" (and "final") are keywords only in certain semantic
>>>> contexts, supporting them requires special care.
>>>
>>> override and final have the same context as `const' for methods, so we
>>> could take that as a model. Skimming over cc-langs.el didn't show an
>>> obvious place for it, though.
>> 
>> Yes, but "const" has a meaning in other places as well.  That's why it is 
>> dealt with in `c-type-modifier-kwds'.  I think the problem is similar for 
>> "noexcept".  I've simply added it to `c-type-modifier-kwds' for now.  But it's 
>> actually the wrong place.  However unlike "override" and "final", there is 
>> also an operator version of "noexcept".
>
> C++11 introduced the noexcept and constexpr keywords. They're always
> keywords. "override" and "final" are different. Please don't go hack
> those into cc-engine. Better to leave them unfontified than to fontify
> perfectly good identifiers as keywords.

Is this the problem? *If* hacking c-mode font-lock system ends with
"override" and "final" fontified as specifiers, is that so terrible? Are
those identifiers so popular? C-mode already gets confused very often
about how to fontify certain non-C-ish chunks of C++ code, so having
"override" and "final" fontified as specifiers everywhere seems a
non-issue to me. What's more annoying is to not fontify them on method
declarations, because my first reaction when glancing at that code is to
assume a typo.

> They're not like "const" at all.

As far as c-mode is concerned, they are like "certain variety of const."
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.

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

[Daniel Colascione]

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

On 11/18/2014 10:01 AM, Óscar Fuentes wrote:
> Daniel Colascione <dancol@dancol.org> writes:
> 
>> On 11/18/2014 08:36 AM, Rüdiger Sonderfeld wrote:
>>> On Tuesday 18 November 2014 15:47:43 Óscar Fuentes wrote:
>>>> Daniel Colascione <dancol@dancol.org> writes:
>>>>>>> The "alignof" keyword is the only one still missing.
>>>>>>
>>>>>> From the top of my head: override is also missing.
>>>>>
>>>>> Because "override" (and "final") are keywords only in certain semantic
>>>>> contexts, supporting them requires special care.
>>>>
>>>> override and final have the same context as `const' for methods, so we
>>>> could take that as a model. Skimming over cc-langs.el didn't show an
>>>> obvious place for it, though.
>>>
>>> Yes, but "const" has a meaning in other places as well.  That's why it is 
>>> dealt with in `c-type-modifier-kwds'.  I think the problem is similar for 
>>> "noexcept".  I've simply added it to `c-type-modifier-kwds' for now.  But it's 
>>> actually the wrong place.  However unlike "override" and "final", there is 
>>> also an operator version of "noexcept".
>>
>> C++11 introduced the noexcept and constexpr keywords. They're always
>> keywords. "override" and "final" are different. Please don't go hack
>> those into cc-engine. Better to leave them unfontified than to fontify
>> perfectly good identifiers as keywords.
> 
> Is this the problem? *If* hacking c-mode font-lock system ends with
> "override" and "final" fontified as specifiers, is that so terrible? Are
> those identifiers so popular? C-mode already gets confused very often
> about how to fontify certain non-C-ish chunks of C++ code, so having
> "override" and "final" fontified as specifiers everywhere seems a
> non-issue to me. What's more annoying is to not fontify them on method
> declarations, because my first reaction when glancing at that code is to
> assume a typo.

Patch cc-engine to recognize the proper context if you care so much. Until you can do that, do not touch cc-mode.
 
>> 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".

> 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.

Do it right or not at all. 


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

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

[Óscar Fuentes]

Daniel Colascione <dancol@dancol.org> 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.

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

[Daniel Colascione]

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

On 11/17/2014 06:41 PM, Rüdiger Sonderfeld wrote:
> On Sunday 16 November 2014 19:07:24 Óscar Fuentes wrote:
>> What was available in Alan's cc-mode c++11 branch was merged long time
>> ago (it was mostly about decltype and auto, IIRC.)
>>
>> It would be nice to apply the patch that started this thread, plus a few
>> other keywords. However, I had no opportunity of testing the adapted
>> patch because I did no C++ coding lately. No doubt someone which is
>> fluent on Emacs' syntax highlighting system could be able to assert the
>> validity of the patch without testing.
> 
> I took the liberty to merge the patch.  I've updated and adjusted it a bit.
> 
> The "alignof" keyword is the only one still missing.  It seems that some 
> extensions to cc-mode might be necessary to include it.
> 
> There is also this patch pending.  But it requires some more work: 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5457

That patch is so bitrotted that it probably requires a complete rewrite.


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