From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] support a few of the new features of C++11 in syntax highlighting Date: Tue, 18 Nov 2014 10:11:57 -0800 Message-ID: <546B8BED.9050208@dancol.org> References: <546B4013.6080507@dancol.org> <878uj85zw0.fsf@wanadoo.es> <3893580.J5y1DMedfv@descartes> <546B7E24.6010408@dancol.org> <87zjbo4cc7.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bsfewg6lqo1WMrBofWDvxNLlJLOjVuRIG" X-Trace: ger.gmane.org 1416334350 9162 80.91.229.3 (18 Nov 2014 18:12:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 18:12:30 +0000 (UTC) To: =?UTF-8?B?w5NzY2FyIEZ1ZW50ZXM=?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 19:12:24 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XqnGJ-0003SJ-AP for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 19:12:23 +0100 Original-Received: from localhost ([::1]:54633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqnGI-00008g-Qm for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 13:12:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqnG3-00008Z-MB for emacs-devel@gnu.org; Tue, 18 Nov 2014 13:12:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqnG0-0006uC-6b for emacs-devel@gnu.org; Tue, 18 Nov 2014 13:12:07 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqnFz-0006u0-QW for emacs-devel@gnu.org; Tue, 18 Nov 2014 13:12:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=L2hURMr+AcQE2IgvW94h6dLuQRSMyEElw/0jDx81Iwk=; b=QqDWaO5wZDJjSDdnzyot9n4bMXkLtZPj/bvnbtg2qAoE0g+ZHgPX+jWVtk0elXJNde7hQwsxd6fKOzzdwHBpKtxmS+8TDtlV5MbMITO0Y2x1dDWZWhv26KFkR9gXo6tX8+6M4zIpOnX9FukS+rGowEgF6BwGo3aeP/rFtqJZoN6BHBaF2Yo5CwJ+Cg0B/UDWzgsiT+2FDJuQ453gIA6ZCuvpZvSMLxibe8gxHaVmT+wgdOICbq6sQKhhP4Hy1GwlqJBDHBoWDvlsA9wV0gkyV2jQGYyjJoAJwkUpJaFShO+aKla+6jDySb0hiJEofe/q9JwVCLeEk+BrR4rMJ+KQ4A==; Original-Received: from [2620:0:1cfe:9a:2ab2:bdff:fe1c:db58] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1XqnFz-00073I-Ct; Tue, 18 Nov 2014 10:12:03 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: <87zjbo4cc7.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177619 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Bsfewg6lqo1WMrBofWDvxNLlJLOjVuRIG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/18/2014 10:01 AM, =C3=93scar Fuentes wrote: > Daniel Colascione writes: >=20 >> On 11/18/2014 08:36 AM, R=C3=BCdiger Sonderfeld wrote: >>> On Tuesday 18 November 2014 15:47:43 =C3=93scar Fuentes wrote: >>>> Daniel Colascione 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 seman= tic >>>>> 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 i= t is=20 >>> dealt with in `c-type-modifier-kwds'. I think the problem is similar= for=20 >>> "noexcept". I've simply added it to `c-type-modifier-kwds' for now. = But it's=20 >>> actually the wrong place. However unlike "override" and "final", the= re is=20 >>> 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. >=20 > Is this the problem? *If* hacking c-mode font-lock system ends with > "override" and "final" fontified as specifiers, is that so terrible? Ar= e > 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 t= o > assume a typo. Patch cc-engine to recognize the proper context if you care so much. Unti= l you can do that, do not touch cc-mode. =20 >> They're not like "const" at all. >=20 > 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 u= sed 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 crea= te a derived mode locally. Do it right or not at all.=20 --Bsfewg6lqo1WMrBofWDvxNLlJLOjVuRIG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUa4vtAAoJEN4WImmbpWBladgP/iP4ZRMVkZZXt/Wtk1ECj5aP b2OJR5bgLeXZgkKERr9XzbcGxx4XxnIOlMzq58aTVLbzBiBmVURF4bMY3k15a3TN WPF2mm5JGyNKMVGyIW86Y+Hjg/KgXFHqz4hzp8TFDVJXOIBzOf5nG9qAFawQz2+n +bATAqHv6ws7OhNfvUz61fRIQ8VjvEYY2QeF1GHojBtt4n3y8DZfpGcqw+IfBuZ9 tVkxX2KutmI17uhaDwJgdUGGgOBJ63DtGpPpN9+FY1k4qm34Zor+Xdk+qV/7jK6/ 5WZ5Rk2mpbcNGSci4BDbsvIMTCmy45uyZjyRteQzoebUSq1OmBHBXNSYEO/GSdMg YDW5r2R4Twi75wh+oBn1WcAqBx5oP2UXiLznY2rE69LHqYcknjloSk9BaaBWucYl GEaphrTUFpOO6lOPCXm2sXaIz47zwN4XyVaZ//H+W/6MK1zVpc7DXGbvqgKgKHZQ mymFl88oAq0RK7YF+nCb7VGl50NbrzXZn2ekQifApdZdhO6zqMHB9UR7PIFEdms5 gK8rUpVxN0iFD2MkLJLSR0FCF+gHDLRRsWVl0+n6opLCYOJ5dBxkI5nB1lEBgeC8 7d3bTX/bM0jA5gHFLbp2ouOhuTVxeUQuUUxZlSXQ2LD2nXI+qSEyhq5yaWlWkTcQ 7oDjysxPwG0RyzeqY7PG =bJtC -----END PGP SIGNATURE----- --Bsfewg6lqo1WMrBofWDvxNLlJLOjVuRIG--