From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Marshall, Simon" Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: RE: FW: Font-lock misfontifies foo::bar in C++ Date: Wed, 16 Aug 2006 15:35:31 +0100 Message-ID: <81CCA6588E60BB42BE68BD029ED48260097F9E6B@wimex2.wim.midas-kapiti.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1155738913 7875 80.91.229.2 (16 Aug 2006 14:35:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 Aug 2006 14:35:13 +0000 (UTC) Cc: "'emacs-devel@gnu.org'" Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Wed Aug 16 16:35:10 2006 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GDMTz-0002vj-B4 for sf-cc-mode-help@m.gmane.org; Wed, 16 Aug 2006 16:34:59 +0200 Original-Received: from sc8-sf-list1-new.sourceforge.net (unknown [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 98476121A5; Wed, 16 Aug 2006 07:34:58 -0700 (PDT) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GDMTx-0005dJ-Ps for cc-mode-help@lists.sourceforge.net; Wed, 16 Aug 2006 07:34:57 -0700 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.44) id 1GDMTw-0006c5-Vw for cc-mode-help@lists.sourceforge.net; Wed, 16 Aug 2006 07:34:57 -0700 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GDMTq-0002gW-Vw for bug-cc-mode@gnu.org; Wed, 16 Aug 2006 10:34:50 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1GDMa6-0003Bn-AM for bug-cc-mode@gnu.org; Wed, 16 Aug 2006 10:41:19 -0400 Original-Received: from [80.69.8.190] (helo=cluster-a.mailcontrol.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GDMa5-0003BS-PV; Wed, 16 Aug 2006 10:41:18 -0400 Original-Received: from wimex2.wim.midas-kapiti.com ([217.196.233.101]) by rly05a.srv.mailcontrol.com (MailControl) with ESMTP id k7GEYgRv018124; Wed, 16 Aug 2006 15:34:42 +0100 Original-Received: by wimex2.wim.midas-kapiti.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Aug 2006 15:35:37 +0100 Original-To: "'bug-cc-mode@gnu.org'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scanned-By: MailControl A-07-04-01 (www.mailcontrol.com) on 10.65.0.115 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on monty-python X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: cc-mode-help-bounces@lists.sourceforge.net Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:3750 gmane.emacs.devel:58444 Archived-At: > OK. Just to clarify where I think we are - In this: > > void foo::bar() > > , "foo" gets font-lock-constant-face. > > (i) We both agree that this face assignment is deliberate and > documented: On the page "Faces" in the CC Mode manual, it says: > * Name qualifiers and identifiers for scope constructs are > fontified like labels. > * Label identifiers get `font-lock-constant-face' if it exists, > `font-lock-reference-face' otherwise. > (ii) You're saying that fontifying "foo::" like a label is bad. > > ############################################################## > ########### > > > > Example 3: > > > > foo::bar > > > > "foo" doesn't specify the type of anything here either. Its > > > use is to tell in which scope "bar" is declared. Hence it > > > gets a face that is different from the type face. I call this > > > use "identifier qualifier". > > > > To make this more obvious/precise, you could perhaps > > > introduce another face name variable, say > > > c-qualifier-face-name, and make a suitable mapping of it onto > > > one of the existing font-lock faces. I don't think it should > > > be mapped to the type face though, because it would be used > > > for namespace names too. In lack of better alternatives I > > > chose to map it as I did. > > > I think c-qualifier-face-name would be a good idea, but I think it odd to > > pick a face for its value that is definitely wrong. References are used for > > constants and labels. Why not pick a face that is usually right, eg, the > > type face? > > I'm at a disadvantage here, because I don't feel at all strongly about > what the right face is for "foo::", as long as it's visually distinct. > In fact I'd never really noticed that it was font-lock-constant-face. > > You're an expert on font-lock, though. Why would f-l-type-face be any > better? Martin feels quite strongly, that "foo::bar" is not using foo > "in a type context", and has referred to Pike (one of CC Mode's other > languages), where a constant declaration is a special case of a class > declaration. OK, let's take this qualifier thing at face value. (In C++, "foo" in "foo::bar" is a qualifier. It is the name either of a type or a namespace.) class CLASS; // CLASS is in font-lock-type-face namespace NAMESPACE; // NAMESPACE is now in font-lock-constant-face void CORN::fubar(); // CORN is now in font-lock-constant-face (In Emacs 19/20/21, CLASS, NAMESPACE and CORN are all in font-lock-type-face.) By the qualifier argument, CORN cannot be in the face used for type names, because it is not used "in a type context". But, by the same argument, it cannot be in the face used for namespace names either, because it is not used in a namespace context. (a) Since CORN is fontified in the same face as namespace names, your qualifier argument leads me to the conclusion that the current behaviour is broken. By the qualifier argument, if you really wanted to distinguish between namespace names, type names and qualifiers, you would have to use 3 distinct faces. This leads me to my original bug report. (b) The use of font-lock-constant-face for either NAMESPACE or CORN is wrong, because that face is for constants and labels. That face is quite explicitly documented that way. Therefore, by your (a) and my (b), you need to use a new face for NAMESPACE and a new face for CORN. To return to the qualifier argument. The contexts are (1) a type name in a type context, (2) a type name in a qualifier context, (3) a namespace name in a namespace context, and (4) a namespace name in a qualifier context. Currently, you distinguish between (1) and (2,3,4). This is wrong regardless of the faces used. Personally, I do not see the value in distinguishing between each of them (I hope you don't think that the qualifier argument implies that you should!), or even between (1), (3) and (2,4). I don't buy the qualifier argument at all. There would be too many faces for one, and too little practical gain for another. To return to my original report. I originally made (1,2,3,4) be fontified as a type name mostly for ease of implementation and performance, not because I had a particular view of whether it was worth distinguishing between them. I think it would be useful to change this, so that (1,2) are distinguished from (3,4). But you shouldn't use font-lock-constant-face to fontify a namespace name. That's why I say it would be better to fontify as a type name, at least until type names and namespace names can be dealt with individually as I suggest below. (I don't see the relevance of Pike---this is just about C++.) > > Perhaps a better solution would be to add a > > c++-font-lock-extra-qualifiers, akin to c++-font-lock-extra-types, > > that is a list of qualifier names. I would suggest that, by default, > > these could be fontified in font-lock-type-face, but perhaps you might > > like to add a font-lock-qualifier-face to allow users (or modes) to > > specify what they want. For C++, this variable could default to > > '("std") or somesuch. > > > So, by default, "foo::bar" would not cause "foo" to be fontified in any > > face. If the user wanted it to be fontified, they would modify > > c++-font-lock-extra-types if it were a type or > > c++-font-lock-extra-qualifiers if it were a namespace. > > > WDYT? > > OK; maybe. But that would definitely be a new feature for CC > Mode 5.32, not something to slip in to 5.31.n in a hurry. > > As regards f-l-constant-face on "foo::": I don't really want to change > it, since this would be a lot of work. Changing the code in cc-fonts.el > and the text in the manual would be relatively quick and easy, but then > I'd have to update the regression test program 000tests.el, and > recalcuate all the "face files" in the test suite, diff them with the > existing versions, and commit them to the CVS repository. There are 166 > files.face involved. I would surely also get complaints from people > who've got used to the existing fontification. I don't recall any complaints back in the Emacs 19/20/21 days when it fontified class names and namespace names as type names. Maybe I'm being presumptive, but I'm sure those who noticed type names and namespace names now being fontified as constants/labels won't mind it going back to be as type names. > So why is f-l-constant-face so jarring here? I can see that it's not > particularly appropriate, but what is there about it that makes it > repulsive and ghastly, that raises a calm competent hacker's hackles? > (This isn't a rhetorical question.) I don't claim to be calm or competent, and I never said it was repulsive or ghastly. But, visual cues are not helpful if they are wrong, particularly when they are something as fundamental as classes and namespaces are in C++. The only thing that could raise my hackles is that I feel I'm just repeating myself. And this has been going on nearly 2 months. I don't mind resolution taking that long---nobody is paid to do this---it's the lack of progress on such a simple issue that is frustrating. But perhaps I share some of the blaim for that. Thanks, Simon. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642