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 11:20:47 +0000 (GMT) Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1140089329 32007 80.91.229.2 (16 Feb 2006 11:28:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2006 11:28:49 +0000 (UTC) Cc: Stefan Monnier , 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:44 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 1F9hJH-0000bG-GO for sf-cc-mode-help@m.gmane.org; Thu, 16 Feb 2006 12:28:32 +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 AC5A5320C0; Thu, 16 Feb 2006 03:28:06 -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 1F9hHw-0002UX-C3 for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 03:27:08 -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 1F9hHt-0001pL-Sk for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 03:27:08 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9hHs-0005iu-8g for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 06:27:04 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9hMw-0004AD-Ef for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 06:32:21 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F9hMr-000499-Ge; Thu, 16 Feb 2006 06:32:14 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id LAA00427; Thu, 16 Feb 2006 11:20:47 GMT X-Sender: root@acm.acm Original-To: Ralf Angeli In-Reply-To: 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 11:20:47 +0000 (GMT) Xref: news.gmane.org gmane.emacs.cc-mode.general:3026 gmane.emacs.devel:50609 Archived-At: Hi, Ralf! On Wed, 5 Feb 2006, Ralf Angeli wrote: >* Alan Mackenzie (2006-02-15) writes: >> On Sun, 12 Feb 2006, Stefan Monnier wrote: >>>.... 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. >> 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. >> (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). f-l-f-region is regularly called when there is no >> buffer change in progress. >> 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. They >> shouldn't be intermingled with eachother. >This is all well and good, but in contrast to the after-change hook, a >hook in `font-lock-default-fontify-region' could not only adjust the >region after a change but also during fontification by chunks as done >by jit-lock. (That's an advantage I haven't noticed before.) That is horrible. f-l-d-f-r currently fontifies the region requested by the caller, not a different region that Font Lock finds more convenient. If we change its functionality, something somewhere will surely break. >Following your reasoning of separating the determination of the region >to be fontified from the fontification itself would require that >jit-lock determines the chunks to be fontified more intelligently. I don't follow that. There are several different ways that jit-lock determines its chunks. There's after-change, after-scrolling, stealth, at least. I don't see why determining a jit-lock after-change region need have anything to do with determining an after-scrolling or stealth region. >Ralf -- 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