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 15:12:31 +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 1140103247 17637 80.91.229.2 (16 Feb 2006 15:20:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2006 15:20:47 +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 16:20:34 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 1F9kvN-0003Ew-21 for sf-cc-mode-help@m.gmane.org; Thu, 16 Feb 2006 16:20:06 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 3A5C213E28; Thu, 16 Feb 2006 07:20:04 -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 1F9kur-0005H9-8o for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 07:19:33 -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 1F9kup-0007cg-Sl for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 07:19:33 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9kuo-00079S-4W for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 10:19:30 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9kzu-0005eo-Kq for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 10:24:49 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F9kze-0005dE-O4; Thu, 16 Feb 2006 10:24:32 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id PAA00654; Thu, 16 Feb 2006 15:12:32 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 15:12:31 +0000 (GMT) Xref: news.gmane.org gmane.emacs.cc-mode.general:3032 gmane.emacs.devel:50615 Archived-At: Hi, Ralf! On Thu, 16 Feb 2006, Ralf Angeli wrote: >* Alan Mackenzie (2006-02-16) writes: >> Hi, Ralf! >> On Wed, 5 Feb 2006, Ralf Angeli wrote: >>>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. >As Stefan already pointed out this is not the case because the region >may be extended if `font-lock-multiline' is activated. >> 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. >I was referring to stealth fontification during which jit-lock >fontifies chunks of the size determined by `jit-lock-chunk-size' one >after another. If the start of one of those chunks is located inside >of a "<<...>>" construct an after-change hook will not let me extend >the region backwards to the starting tag in that case because there >hasn't happened a change. OK, I've got you now! It sounds like jit-lock perhaps isn't really the right strategy for mark-up modes. But it seems like a hook is required in the jit-lock stealth bit. This is surely needed as _well_ as the after-change hook that expands the region, not instead of it. For example, if a change were the insertion of a ">> .... <<", the region to fontify would include some text before the new insertion. The after-change-expand-region hook would detect this by using information recorded by a before-change-function. AWK Mode uses this stragem. A stealth-expand-region hook would scan back to the ">>", and stop. >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