From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: POC: customizable cc-mode keywords Date: Fri, 16 May 2014 17:52:27 +0000 Message-ID: <20140516175226.GB3267@acm.acm> References: <53632C6F.5070903@dancol.org> <20140511211351.GC2759@acm.acm> <536FEA43.5090402@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1400263042 5445 80.91.229.3 (16 May 2014 17:57:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 May 2014 17:57:22 +0000 (UTC) Cc: Emacs developers To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 16 19:57:15 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 1WlMNO-0000ZP-8h for ged-emacs-devel@m.gmane.org; Fri, 16 May 2014 19:56:58 +0200 Original-Received: from localhost ([::1]:37124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlMNN-0008PJ-PG for ged-emacs-devel@m.gmane.org; Fri, 16 May 2014 13:56:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlMND-0008P3-T9 for emacs-devel@gnu.org; Fri, 16 May 2014 13:56:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlMN6-0001ik-Dd for emacs-devel@gnu.org; Fri, 16 May 2014 13:56:47 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:37960 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlMN6-0001fk-4G for emacs-devel@gnu.org; Fri, 16 May 2014 13:56:40 -0400 Original-Received: (qmail 16295 invoked by uid 3782); 16 May 2014 17:56:37 -0000 Original-Received: from acm.muc.de (pD951BC19.dip0.t-ipconnect.de [217.81.188.25]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 16 May 2014 19:56:36 +0200 Original-Received: (qmail 3565 invoked by uid 1000); 16 May 2014 17:52:27 -0000 Content-Disposition: inline In-Reply-To: <536FEA43.5090402@dancol.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 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:171889 Archived-At: Hi, Daniel. On Sun, May 11, 2014 at 02:23:15PM -0700, Daniel Colascione wrote: > On 05/11/2014 02:13 PM, Alan Mackenzie wrote: > > Hi, Daniel. > > 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 preprocessor > >> heavily. > > 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. OK, so we need to have configurable "noise macros", just as we already have configurable "macros ending with a semicolon" and "extra types". [ .... ] > >> The patch below adds customizable options for additional C-family > >> language "keywords". > >> To add this feature, we have to change how cc-mode evaluates its > >> language variables. > > :-) > >> 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. > > Do we, now? You can imagine I've one or two reservations about this > > idea. > What's your alternative? Turning the pertinent c-lang-defvars, and only these, into configurable variables in cc-vars.el. [ .... ] > >> 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 work > >> using dynamic evaluation. I can live with this performance regression. > > 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. I'm sorry, but I can't make much of that paragraph; it doesn't seem coherent to me. What I still don't understand is why it should be necessary to make _all_ c-lang-defvars configurable variables, rather than just those one or two directly involved in parsing these awkward C (etc.) declarations. As I said, I'm not at all happy at making such a massive change to CC Mode's architecture. There would surely be unforeseen consequences, some of which might well be negative. -- Alan Mackenzie (Nuremberg, Germany).