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: POC: customizable cc-mode keywords Date: Sun, 11 May 2014 14:23:15 -0700 Message-ID: <536FEA43.5090402@dancol.org> References: <53632C6F.5070903@dancol.org> <20140511211351.GC2759@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3bF1A9p9kSp4IdJ43DePWSrm7Ft3toIHi" X-Trace: ger.gmane.org 1399843411 27157 80.91.229.3 (11 May 2014 21:23:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 May 2014 21:23:31 +0000 (UTC) Cc: Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 11 23:23:26 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 1WjbDQ-00073u-1l for ged-emacs-devel@m.gmane.org; Sun, 11 May 2014 23:23:24 +0200 Original-Received: from localhost ([::1]:34398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjbDP-0006L0-JS for ged-emacs-devel@m.gmane.org; Sun, 11 May 2014 17:23:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjbDL-0006Ki-A7 for emacs-devel@gnu.org; Sun, 11 May 2014 17:23:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjbDK-0002O5-5v for emacs-devel@gnu.org; Sun, 11 May 2014 17:23:19 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:41985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjbDJ-0002Nz-Nj for emacs-devel@gnu.org; Sun, 11 May 2014 17:23:18 -0400 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:CC:To:MIME-Version:From:Date:Message-ID; bh=ieaDMwosHDCzCPi6OCYDHtYVUdGIku+9e1FKzFSltlk=; b=JP9BZRZ4gTv9jLWxdijjMS1OXz/FQpAiabUsvQyE/UBFqR468fXR+UeDdVEgtHo9JiA2MGcsmnUjs6y7ru+USCUva3pTCQEbw/kFJe9cNiZCX0tPeVoQGdTQV2Qe8ikdk8Z9jT8BmK3qOEJcKGj3CDsp/TKc1NxjiNwQXd8mjxqlHoW7dV4jzwpk7PSHLR/F5a4tfb3lQDAtsDmt8O7rlGj4I3Y974wNVrQHj+NrjrDD/tW+t/yqEiwHcX6vYSoN1Sbi3DpieNkk3bN3utLdrmgfoggna7pAOcOrenZzVpXGbM+ByxnJMg6ZekCXwXB0lTQRgh/vrBoRIJRtHhLNvw==; Original-Received: from [2601:8:b240:2a1::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WjbDI-0006d4-Vx; Sun, 11 May 2014 14:23:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <20140511211351.GC2759@acm.acm> X-Enigmail-Version: 1.6 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:171807 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3bF1A9p9kSp4IdJ43DePWSrm7Ft3toIHi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/11/2014 02:13 PM, Alan Mackenzie wrote: > Hi, Daniel. >=20 > On Thu, May 01, 2014 at 10:26:07PM -0700, Daniel Colascione wrote: >> cc-mode has trouble with parsing dialects of C that use the preprocess= or >> heavily. >=20 > This has been true since 4004 BC, since C hackers are able to write > monstrosities using macros. But we do our best to cope with the less > outlandish variants. We have to address the syntactic confusion these macros cause somehow, and I don't think automatic heuristics will be sufficient. I'm really sick of seeing a lot of code I look at in the real world misfontified. >> Consider this example from the Linux kernel: >=20 >> static int perf_event_period(struct perf_event *event, u64 __user *a= rg) >=20 >> __user is defined to some GCC static analysis nonsense, but since >> cc-mode doesn't know that, we see __user fontified in >> font-lock-variable-name-face and *arg untouched. This example is fairl= y >> benign (if ugly), but there are other cases where variations in >> pre-processor C dialect confuse cc-mode in larger regions, leading to >> odd fontification and indentation. >=20 >> The patch below adds customizable options for additional C-family >> language "keywords". >=20 >> To add this feature, we have to change how cc-mode evaluates its >> language variables. >=20 > :-) >=20 >> Today, we use clever macros to hard-code the values of all cc-mode >> language variables into the mode functions of each cc-mode major mode >> function or into c-init-language-vars-for, but in order to allow users= >> to customize cc-mode syntax, we have to be able to recompute language >> constants and variables at runtime. >=20 > Do we, now? You can imagine I've one or two reservations about this > idea.=20 What's your alternative? > It's far from clear that this level of customisation is a good > thing. The current idea is that the language variables are for creatin= g > new CC Mode languages, not as a means of customisation. They're public either way. >> The new code simply evaluates cc-mode language setter forms at mode >> initialization instead. This approach is slower, but not by much: it >> takes 0.9ms to set up cc-mode's ~130 language variables using the >> precompiled function approach, while it takes 1.6ms to do the same wor= k >> using dynamic evaluation. I can live with this performance regression.= >=20 > Have you considered turning the pertinent language variables into > customisable variables in cc-vars.el, along the lines of > *-font-lock-extra-types? The patch includes user-customizable variables. The actual cc-lang constants aren't advertised as user customization points. The existing type customization is simple because it's done in isolation from the rest of cc-mode's syntactic analysis. Actually understanding keywords requires deeper, cascading changes to core language constants. The only practical way of making that happen is to allow these constants to change at runtime. --3bF1A9p9kSp4IdJ43DePWSrm7Ft3toIHi 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTb+pDAAoJEMAaIROpHW7IJAMP/003hGOYl8MbuR20bK862DQi Lun8sO+l4RAxqLXr/+i2kZFh58gqbdAunre7ooR3fKG1tgEp7jaS4Q4FdcqZ1Zar mjeODx0IkBsHr2aAQqcOVEuicZSYpFmZzmLiwtaL+krEtwYy3G1x9pEes4hb3FOY 3UrJ2eZERhCxwZ0Xi5lZYPJIY3hVs4qE4NlG4p1oX9lv6ruj/P7Lu5bcxJHkLRaa I/P412cHtluMSbZqCiplOnpyhLCcQSVSBTOcVY1bA4gIGzAQwAF8/evYCpa+o5t7 4r7+OgN/VPonZmKuCVar7+MR31msiA1RTUJ5jA6lpnNdmIEOWrhpf8lYgrbCZjlf be4hCMbhfIuQ/bkI/owBC7tofsEn6MzO1AxcgJ85UUck8On0DMkor3ZrcSET7QNR JNGs2kQvLNP++XQdRbc8whwTzD+F9Yyw6zthMSEma1D/2qaBRyTeFm+0tUMbKtuR 304sqX9nKzCVDnMlugCBA6Lnfrr5XD+nAErXPibR5RkgwYIooz5hB+H4Epi330h9 WZFNbyzaBZ1uUMNdLZhdjZ6cFjv05AX0iCO/Y4/d7kQ0DpF36hydbtUI+phwA8NJ hBJiikUzblfyT68UOZlzbtCxWaEqarA0A3voNqXbCnM+cAdvEvUzSg1NtoBxAO+g ZvXiP8z6ObwWJxvJc0PT =PiP+ -----END PGP SIGNATURE----- --3bF1A9p9kSp4IdJ43DePWSrm7Ft3toIHi--