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: Sun, 11 May 2014 21:13:51 +0000 Message-ID: <20140511211351.GC2759@acm.acm> References: <53632C6F.5070903@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1399843112 23599 80.91.229.3 (11 May 2014 21:18:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 May 2014 21:18:32 +0000 (UTC) Cc: Emacs developers To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 11 23:18:25 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 1Wjb8b-0006Mw-4T for ged-emacs-devel@m.gmane.org; Sun, 11 May 2014 23:18:25 +0200 Original-Received: from localhost ([::1]:34386 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjb8a-0004rw-D4 for ged-emacs-devel@m.gmane.org; Sun, 11 May 2014 17:18:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjb8P-0004rd-T6 for emacs-devel@gnu.org; Sun, 11 May 2014 17:18:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wjb8D-0000zN-1o for emacs-devel@gnu.org; Sun, 11 May 2014 17:18:13 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:40761 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjb8C-0000z5-Nw for emacs-devel@gnu.org; Sun, 11 May 2014 17:18:00 -0400 Original-Received: (qmail 6952 invoked by uid 3782); 11 May 2014 21:17:57 -0000 Original-Received: from acm.muc.de (pD951AB04.dip0.t-ipconnect.de [217.81.171.4]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 May 2014 23:17:56 +0200 Original-Received: (qmail 3786 invoked by uid 1000); 11 May 2014 21:13:51 -0000 Content-Disposition: inline In-Reply-To: <53632C6F.5070903@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:171806 Archived-At: 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. > Consider this example from the Linux kernel: > static int perf_event_period(struct perf_event *event, u64 __user *arg) > __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 fairly > 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. > 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. It's far from clear that this level of customisation is a good thing. The current idea is that the language variables are for creating new CC Mode languages, not as a means of customisation. > 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? > As implemented, the keyword list can only be customized globally, but > it'd be nice to be able to do something buffer-local too. [ snipped patch for now. ] -- Alan Mackenzie (Nuremberg, Germany).