From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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:27:37 -0500 Message-ID: <87slqjcorr.fsf-monnier+emacs@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1140107300 1722 80.91.229.2 (16 Feb 2006 16:28:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2006 16:28:20 +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 17:28:14 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 1F9lzB-0002h0-1F for sf-cc-mode-help@m.gmane.org; Thu, 16 Feb 2006 17:28:05 +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 1E8E589C67; Thu, 16 Feb 2006 08:28: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 1F9lz5-000391-1c for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 08:27:59 -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 1F9lz2-000378-9Q for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 08:27:59 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9lyo-0000WM-Na for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 11:27:45 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9m3v-0002pa-PN for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 11:33:02 -0500 Original-Received: from [209.226.175.188] (helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F9m3v-0002pU-EX; Thu, 16 Feb 2006 11:32:59 -0500 Original-Received: from alfajor ([67.71.116.200]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060216162738.OBHI21965.tomts25-srv.bellnexxia.net@alfajor>; Thu, 16 Feb 2006 11:27:38 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id 6BDEAD7341; Thu, 16 Feb 2006 11:27:37 -0500 (EST) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Thu, 16 Feb 2006 09:51:50 +0000 (GMT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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 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:27:37 -0500 Xref: news.gmane.org gmane.emacs.cc-mode.general:3034 gmane.emacs.devel:50617 Archived-At: >>> (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. [ Follows some exaggeration which I find tends to weaken your point, so I prefer to cut it. ] But the fact is: - font-lock-fontify-region doesn't have a docstring a doesn't seem documented in the Emacs manual either. So when you say "functions MUST do what they say they do", it's not clear to me that font-lock-fontify-region says anything about what it does. - font-lock-fontify-region AFAICT has *never* limited its scope to BEG...END. So anybody expecting font-lock-fontify-region to only fontify from BEG to END is deluding himself. Basically, the way it has been defined and used until now is the following: fontify the smallest region that includes BEG..END and which doesn't start or end in the middle of a font-lock-keyword. For font-lock-keywords which can span several lines, this implies extending the region by the corresponding number of lines. Now the region matched by a given font-lock-keyword can't be automatically determined by font-lock-fontify-region, so the heuristic used is to extend the region to a whole number of lines and if that's not enough some other piece of code (e.g. user-provided code) has to tell it via the font-lock-multiline property (or as I suggest, via a font-lock-extend-region-functions hook). Now let's say you have a multiline element which your font-lock-keyword is somehow able to (re)highlight line-by-line, then you indeed don't need to extend the region in font-lock-fontify-region. Of course it gets trickier when your font-lock-keyword can (re)highlight your multiline element line-by-line but only if the first line of the element has already been fontified (where it recognizes the element and somehow marks the text so that fontification of further lines is done properly). And even worse if the fontification of the first line only recognizes the whole element depending on some text further down (e.g. a terminator), since then the first (and succeeding) line(s) need(s) to be somehow rehighlighted when the terminator is added/removed. For such a situation, I currently don't know of a "canonical" way to get font/jit-lock to do the right thing, other than to simply force the whole multiline element to always be rehighlighted as a whole (i.e. defeating your efforts to make your font-lock-keyword able to (re)highlight on a line-by-line basis). If that's the case you're trying to solve, then an after-change-function which marks the whole multiline entity for refontification whenever the terminator is added/removed won't cut it: if the first line is outside of the window, jit-lock won't refontify it. Maybe what will cut it is: using some kind of after/before-change-function (which doesn't have to be in font-lock-after-change-function) detect when a terminator is added/removed and in that case add a font-lock-multiline property on the whole element (which will cause the whole element to be (re)fontified not matter what jit-lock thinks, but the whole-element fontification will only happen this one time since the font-lock-multiline property is removed afterwards). Another way: move the special treatment of the first line from font-lock-keywords to font-lock-syntactic-keywords. Then the after/before-change-function only needs to move jit-lock-context-unfontify-pos. Yet another way: again, move the special treatment of the first line from font-lock-keywords to font-lock-syntactic-keywords, and have it place a jit-lock-defer-multiline property on the whole element. But if you need the terminator to determine whether and where is the whole element, you clearly can't use that since you wouldn't know where/when to put that property such that adding a terminator causes the appropriate refontification. Stefan ------------------------------------------------------- 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