From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ivan Andrus Newsgroups: gmane.emacs.bugs Subject: bug#15211: 24.3.50; Incorrect fontification in c++-mode Date: Tue, 10 Sep 2013 14:04:31 -0600 Message-ID: <143319A4-5908-4B0C-9B33-D3AA59142260@gmail.com> References: <20130831205645.GA4066@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1378843521 19037 80.91.229.3 (10 Sep 2013 20:05:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Sep 2013 20:05:21 +0000 (UTC) Cc: 15211@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 10 22:05:23 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VJUBf-0005aG-EV for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Sep 2013 22:05:23 +0200 Original-Received: from localhost ([::1]:59829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJUBe-0008QT-Ab for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Sep 2013 16:05:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJUBV-0008Nf-O5 for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2013 16:05:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJUBQ-0002JK-HD for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2013 16:05:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJUBK-000253-8z; Tue, 10 Sep 2013 16:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VJUBJ-0004lK-KV; Tue, 10 Sep 2013 16:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ivan Andrus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 10 Sep 2013 20:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15211 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 15211-submit@debbugs.gnu.org id=B15211.137884348618284 (code B ref 15211); Tue, 10 Sep 2013 20:05:01 +0000 Original-Received: (at 15211) by debbugs.gnu.org; 10 Sep 2013 20:04:46 +0000 Original-Received: from localhost ([127.0.0.1]:53280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VJUB2-0004kp-VA for submit@debbugs.gnu.org; Tue, 10 Sep 2013 16:04:45 -0400 Original-Received: from mail-ob0-f175.google.com ([209.85.214.175]:44845) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VJUB0-0004kZ-Oz for 15211@debbugs.gnu.org; Tue, 10 Sep 2013 16:04:43 -0400 Original-Received: by mail-ob0-f175.google.com with SMTP id xn12so7577785obc.6 for <15211@debbugs.gnu.org>; Tue, 10 Sep 2013 13:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d70X/e1DByC8iVyO5Eoz5MNP5KirAgJ22lZQ6uBHmY0=; b=jNEx3DL2JccZ0p06QEme4dRPK5NziU+hDuSrphPhHIgCYigOgSLVh/vmtTyJsntL+d BmqigoUoVcaKV9R5pG5oIhHhVIbyzE74Yl35QqiMHlAxb1vd8RlOEQXhS3y1Oy6JMH2r 8Dc+5LG2WUwwTKRzIA29zPu0HsK9UkDGyP4XlG53ltpcDBdWGcVwReCHSRboyfAW32zR k20eLxxJAlfjj/eWfJnUmydhkCyTC1oVcSzxKBvgB8C/N+WFHO04tL2lXSPlBLEssbOt 6C8yH8u+yE+Qq7ugmS7sFD9epTnU6cwoSuZ+uoL2G2iD73J6LXn7G7w1MbxajrK5ahs2 IDsQ== X-Received: by 10.60.134.230 with SMTP id pn6mr7101871oeb.52.1378843476926; Tue, 10 Sep 2013 13:04:36 -0700 (PDT) Original-Received: from [192.168.1.185] (c-67-174-98-235.hsd1.co.comcast.net. [67.174.98.235]) by mx.google.com with ESMTPSA id d3sm23058242oek.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 13:04:35 -0700 (PDT) In-Reply-To: <20130831205645.GA4066@acm.acm> X-Mailer: Apple Mail (2.1508) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:78190 Archived-At: On Aug 31, 2013, at 2:56 PM, Alan Mackenzie wrote: > Hi, Ivan. >=20 >> In C and C++ it is legal to place the const to the right of the type = as below: >=20 >> Json parseJson( string const &json ); >=20 >> However, this results in "string" not being fontified as a type >> (i.e. with `font-lock-type-face'). It seems to work some times, but = the >> minimal example above does not when starting from `emacs -q`. >=20 > Yes. There is special code in `c-forward-type' that causes different > return codes for "string const" and "string". These two return codes = are > specifically differentiated (at the end of `c-forward-decl-or-cast-1') > when deciding whether or not to fontify the identifier. >=20 > I've not been able to understand why this code does this - the code = has > been in place for well over a decade, and I've been looking at old = change > logs. The following patch disables the distinction and always = fontifies > the identifier. Please try it out and let me know if any undesirable > side effects occur, or if it doesn't quite fix the problem in real = code: I have been using your diff below for a few days, and I haven't noticed = any negative side effects. There are still two things that don't fontify correctly: #define DELETE_MEMBER =3D delete class Bob { Bob &operator=3D(Bob const &) =3D delete; // fontified (with diff = applied) Bob &operator=3D(Bob const &) DELETE_MEMBER; // not fontified with = or without diff Bob( string ); // string is a `font-lock-type-face' explicit Bob( string ); // string is `font-lock-variable-name-face' }; The first bad fontification seems to be caused because it doesn't = understand the macro which probably can't be helped. The second though = is a bit more concerning, though it seems to be unrelated to the current = bug. I will probably open another bug for it unless you'd prefer I = didn't >=20 > diff -r 45df171f9859 cc-engine.el > --- a/cc-engine.el Sat Aug 31 11:09:30 2013 +0000 > +++ b/cc-engine.el Sat Aug 31 20:32:22 2013 +0000 > @@ -7440,7 +7440,8 @@ > ;; interactive refontification. > (c-put-c-type-property (point) 'c-decl-arg-start)) >=20 > - (when (and c-record-type-identifiers at-type (not (eq at-type = t))) > + (when (and c-record-type-identifiers at-type ;; (not (eq = at-type t)) > + ) > (let ((c-promote-possible-types t)) > (save-excursion > (goto-char type-start) >=20 >=20 > After applying the patch to .../lisp/progmodes/cc-engine.el, just > recompile cc-engine.el with M-x byte-compile-file cc-engine.el, = then > reload cc-engine.elc with M-x load-file cc-engine.elc. >=20 >> Although this is fairly uncommon, there are valid reasons for doing = this >> (see = http://www.dansaks.com/articles/1999-02%20const%20T%20vs%20T%20const.pdf >> for example), and at work it's ubiquitous. The lack of fontification = is >> annoying since it gives me vi envy. :-) >=20 > We can't have that. ;-) Don't worry, it doesn't last long. :-) >> Thanks for the overall excellent cc-mode(s)! >=20 > And thank you for taking the trouble to report this bug, and even more > for such a high quality bug report. Based on how quickly you responded, I wish I had reported it long ago. Thanks again, Ivan=