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, 16 Feb 2006 09:51:50 +0000 (GMT) Message-ID: References: <87fymkdua9.fsf-monnier+emacs@gnu.org> Reply-To: Alan Mackenzie NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1140089332 32017 80.91.229.2 (16 Feb 2006 11:28:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2006 11:28:52 +0000 (UTC) Cc: Ralf Angeli , bug-cc-mode@gnu.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Thu Feb 16 12:28:45 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 1F9hJJ-0000c1-As for sf-cc-mode-help@m.gmane.org; Thu, 16 Feb 2006 12:28:35 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id 7035932937; Thu, 16 Feb 2006 03:28:07 -0800 (PST) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1F9hIB-0002W5-5j for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 03:27:23 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.44) id 1F9hIA-0001tw-Hz for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 03:27:23 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9hI9-0005jd-3y for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 06:27:21 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9hND-0004CC-AX for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 06:32:38 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F9hN3-0004Aq-Co; Thu, 16 Feb 2006 06:32:26 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id JAA00412; Thu, 16 Feb 2006 09:51:50 GMT X-Sender: root@acm.acm Original-To: Stefan Monnier In-Reply-To: <87fymkdua9.fsf-monnier+emacs@gnu.org> 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, 16 Feb 2006 09:51:50 +0000 (GMT) Xref: news.gmane.org gmane.emacs.cc-mode.general:3027 gmane.emacs.devel:50610 Archived-At: Good Morning! On Wed, 15 Feb 2006, Stefan Monnier wrote: >>>>> This patch to font-lock is exactly the sort of change I was thinking of. >>>>> Could someone please install it, then rename >>>>> before-font-lock-after-change-function to >>>>> font-lock-extend-region-function, and rename >>>>> font-lock-run-before-after-change-hook to font-lock-extend-region? >>> .... Based on the name, I suppose it's some kind of hook in >>> font-lock-after-change-function, in which case I'd be tempted to suggest >>> to move it to font-lock-fontify-region instead, to reduce the >>> performance impact and make it easier to deal with lazy-lock&jit-lock >>> since these tend to use their own after-change-function. My original patch patched the \(lazy\|jit\)-lock after-change-functions, too. Maybe it would be cleaner to have a new function, (font-lock-get-after-change-region BEG END OLD-LEN), to return that region. This function would also deal with extending the region to whole lines. After all, the region to fontify must be the same, regardless of the support mode (if any) in use. >> I strongly oppose such a change. With that change: >> (i) font-lock-fontify-region would no longer be fontifying the region >> specified by its paramters, but a different (possibly larger) one. >That's already the case since font-lock-fontify-region will typically not >fontify from BEG to END from the beginning of line before BEG to the end of >line after END. Then that can be extended yet further because of >font-lock-multiline. Nobody has ever complained about this. >So why is it a problem? "Nobody complaining" has never been good evidence for something being OK. Intimidation by authorities (though that doesn't happen here, hi Richard!) will produce the same effect. In fact, if Emacs 22 introduced some wonderful new user facility, and there were NO complaints (or feature requests), most likely nobody would be using it. I think, in general, functions MUST do what they say they do, on the exact parameters given by the caller. For example, if SQRT (9) is returned rather than SQRT (9.00322), because it's "easier to calculate", this would be a bad thing. In fact, Intel did more or less this with some of their chips ~10 years ago. Nobody complained, at least, not for a while. That didn't make it OK. The burden of proof is surely the other way round. If somebody believes that, when a caller calls (font-lock-fontify-region 173 258), it's OK to font lock the region (1 250) instead, the onus is on him to show that this really is OK. >> (ii) the hook function (which recalculates BEG and END) might well refer >> to variables set by a before-change-functions hook. (This is done in AWK >> mode, for example). >Which variables would that be? Just one, actually - c-awk-old-EOLL, in cc-awk.el ~L787 - L811. This records the end-of-logical-line position before the change, in case the change deletes the \ of an escaped newline. >> f-l-f-region is regularly called when there is no buffer change in progress. >Indeed. Again, why is it a problem? It would be a problem if f-l-f-region called the hook function, because it would use c-awk-old-EOLL, which wouldn't now have a meaningful value. Or, the hook would have to code round this, behaving differently depending on where f-l-f-region was called from, which would be a Very Bad Thing. Or have I totally lost the thread of the argument, here? >> Both of these things would make debugging a hook function much more >> difficult than it already is. Determining the region to fontify and >> actually fontifying it are two logically distinct operations. >With jit-lock, the region to fontify is not determined by the >after-change-functions either. (jit-lock-after-change BEG END OLD-LEN) determines that region in a well defined fashion, surely? The after-change (BEG END OLD-LEN) has a critically different meaning from the (BEG END) in (font-lock-fontify-region BEG END). The first of these says how the buffer has been changed, the second defines a region to fontify. Deriving the second of these from the first is precisely the problem we're trying to solve. > Stefan -- Alan. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642