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: cc-mode feature request: ignorable syntax Date: Tue, 06 Dec 2011 11:59:26 -0800 Message-ID: <4EDE741E.5070006@dancol.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7AA4485B9BEF8D06B38BF2F2" X-Trace: dough.gmane.org 1323201590 29413 80.91.229.12 (6 Dec 2011 19:59:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2011 19:59:50 +0000 (UTC) To: Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 20:59:47 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RY1B1-00054n-0k for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 20:59:43 +0100 Original-Received: from localhost ([::1]:51160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY1B0-0001xS-Is for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 14:59:42 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY1Ay-0001xN-8h for emacs-devel@gnu.org; Tue, 06 Dec 2011 14:59:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RY1Ax-0007aS-2N for emacs-devel@gnu.org; Tue, 06 Dec 2011 14:59:40 -0500 Original-Received: from dancol.org ([96.126.100.184]:60901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY1Aw-0007a8-UQ for emacs-devel@gnu.org; Tue, 06 Dec 2011 14:59:39 -0500 Original-Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=[192.168.1.52]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RY1Aq-0000ig-3F for emacs-devel@gnu.org; Tue, 06 Dec 2011 11:59:32 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 X-Enigmail-Version: 1.3.3 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.126.100.184 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:146514 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7AA4485B9BEF8D06B38BF2F2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I work on a codebase that uses a strange dialect of C++ --- it includes m= any new "keywords", annotations, and so on that are #defined away when we compile= so that we produce working code. cc-mode doesn't benefit from these saving preprocessor macros, however, and becomes confused by these annotations. e.g., _Success_(return =3D=3D TRUE) BOOL Foo( _In_ DWORD Blah ) { ... } Until now, I've hacked up my copy of cc-mode to understand our syntax, bu= t this approach isn't sustainable because I inevitably fall behind cc-mode trunk= =2E I have an idea for an alternative that might be generally useful instead: 1. We can define a text property, cc-ignore, that cc-mode will look for w= hen it's about to read a symbol from the buffer. When it finds this property,= it'll skip over all characters until the text property disappears again. Then, = a minor mode can make itself responsible for identifying all non-standard constru= cts in a cc-mode buffer and mark them with cc-ignore so that cc-mode's parsing e= ngine handles the syntactically-valid remainder of the buffer. 2. Create a cc-mode synonym table. My team (much to my chagrin) insists o= n #define struct interface, then using interface IFoo { ... }. Because "int= erface" behaves identically to "struct", I just tried it as "struct" in my cc-mod= e. I wonder whether this mechanism can be made more general. With these changes, I think cc-mode could be made to work for a greater v= ariety of C dialects. Any thoughts? --------------enig7AA4485B9BEF8D06B38BF2F2 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.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk7edCMACgkQ17c2LVA10VtyMwCg6/lcZCHIoCuW1ZMNVeHOBSUv x8oAn0bb0XJZBWFyNklh7hpofnrfvhqs =sVln -----END PGP SIGNATURE----- --------------enig7AA4485B9BEF8D06B38BF2F2--