From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows] Date: Thu, 10 Mar 2005 20:09:44 +0000 (GMT) Message-ID: References: <87u0nj7jds.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1110486984 23396 80.91.229.2 (10 Mar 2005 20:36:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 10 Mar 2005 20:36:24 +0000 (UTC) Cc: emacs-devel@gnu.org, bug-cc-mode@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Thu Mar 10 21:36:23 2005 Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D9UNV-0007zT-1A for sf-cc-mode-help@m.gmane.org; Thu, 10 Mar 2005 21:35:30 +0100 Original-Received: from projects.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 56D8312CE6; Thu, 10 Mar 2005 12:35:25 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1D9UNF-00033n-GS for cc-mode-help@lists.sourceforge.net; Thu, 10 Mar 2005 12:35:13 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by sc8-sf-mx2.sourceforge.net with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41) id 1D9UNE-0000jz-S8 for cc-mode-help@lists.sourceforge.net; Thu, 10 Mar 2005 12:35:13 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D9UNA-0003Vn-1M for bug-cc-mode@gnu.org; Thu, 10 Mar 2005 15:35:09 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1D9UN7-0003x4-NR for bug-cc-mode@gnu.org; Thu, 10 Mar 2005 15:35:06 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D9UN6-0003wz-5j; Thu, 10 Mar 2005 15:35:05 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id UAA00384; Thu, 10 Mar 2005 20:09:45 GMT X-Sender: root@acm.acm Original-To: Stefan Monnier In-Reply-To: <87u0nj7jds.fsf-monnier+emacs@gnu.org> X-Spam-Status: No, hits=-1.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Score: 1.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 1.0 FORGED_RCVD_HELO Received: contains a forged HELO Original-Sender: cc-mode-help-admin@lists.sourceforge.net Errors-To: cc-mode-help-admin@lists.sourceforge.net X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Bug reports, feature requests, and general talk about CC Mode. List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Thu, 10 Mar 2005 20:09:44 +0000 (GMT) X-MailScanner-From: cc-mode-help-admin@lists.sourceforge.net X-MailScanner-To: sf-cc-mode-help@m.gmane.org Xref: news.gmane.org gmane.emacs.cc-mode.general:2273 gmane.emacs.devel:34432 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34432 Hi, Stephan. On Thu, 10 Mar 2005, Stefan Monnier wrote: >> We talked about it in bug-cc-mode just after CC Mode 5.30 had been >> released. (Subject: Advising in cc-awk.el and namespace Date: Wed, 09 >> Jul 2003 13:20:20 -0400). I drew attention then (Jul 2003) to the patch >> I had submitted in 2002, which you acknowledged. However, the topic of >> conversation drifted onto why jit-lock consumed so much processor power. >Ah...topic drift. Sorry about not being more careful. I think it was more me that derailed the topic, but it was a long time ago. >>> Could you explain some more about your two cases (the one in awk and >>> the one in the subject of this article): - how do they use your new >>> before-font-lock-after-change-function hook? [ .... ] >> The patch I proposed would achieve this result via a user supplied >> function. >Well my question was really about "how" rather than "why": what does the >elisp hook code look like for each of the two cases. Sorry, I think I was a bit confused in my last post. We might be talking at cross purposes. The "before-font-lock-after-change-function-hook" never made it into any released code. The advice around font-lock-after-change-function, etc., got into cc-awk.el. >>> - why can't they use the font-lock-multiline property? [ .... ] >> Also, font-lock-multiline doesn't (yet?) exist in XEmacs, so I'd need to >> implement a second solution for XEmacs if f-l-multiline was used. CC >> Mode still supports Emacs 20.x, and I think I found that f-l-multiline >> was introduced later than 20.1 (though I can't remember exactly). >Your new hook won't exist in Emacs-20 either, so this seems irrelevant to >the discussion at hand. It just risks drifting the topic. Hmm. Yes, but- If it got into Emacs now, in 6 or 7 years time major-moders could with good conscience say "we're now dropping support for all versions previous to 22.1", just like we recently said "we're dropping support for Emacs 19.xx, so as to use text properties". It's just a fact of life that major modes can't really use "new" elisp features until they've penetrated fully into the installed user base - after several years and several releases. But that's no reason for not making these enhancements. [ .... ] >> I think, as I have done since 2002, that the major-mode should be able >> to supply functions to determine the start and end of the region to be >> fontified. It seems a natural and idiomatic Emacsy way of doing >> things. >You may be right, but I'd like to see your code first, to see how easy and >robust it is to use your hook. I re-posted my tentative 2002 patch here last night. Or did you mean something else? I think it's robust enough, but it could certainly do with some tidying up. To use it, one must merely set a buffer local variable to the major-mode's function, this function being supplied the after-change's BEGIN END and OLD-LEN, and returning (NEW-BEGIN . NEW-END). I think that variable would be better called `font-lock-get-region-function' than the `before-font-lock-after-change-function' I proposed back then. >On a side note, I'm wondering why you go through so much trouble with >the "unmatched opening quote" in AWK. No other mode does that AFAIK, >even though pretty much every major mode in lisp/progmodes/ has pretty >much the same need AFAICT. Does it have to do with something specific >to AWK, or is it non-specific and maybe it should be done for all modes? No, it was a pure act of unadulterated joyous hacking. It wasn't difficult in AWK, a line oriented language, because the "safe place" from which to begin font-locking is merely the most recent BOL which isn't preceded by a \. In C, it would be somewhat trickier, but not too difficult. I think this putting of warning-face on unmatched quotes would be a good idea generally. Not stunningly important in itself, but one of these minor details, the sum total of which makes Emacs such a joy to use. > Stefan -- Alan Mackenzie (Munich, Germany) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click