From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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: Fri, 17 Feb 2006 08:48:45 +0100 Message-ID: <43F57FDD.9010409@gmx.at> References: <87slqjcorr.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1140163092 16351 80.91.229.2 (17 Feb 2006 07:58:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Feb 2006 07:58:12 +0000 (UTC) Cc: Alan Mackenzie , bug-cc-mode@gnu.org, Ralf Angeli , rms@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Fri Feb 17 08:58:09 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 1FA0V8-00007I-KH for sf-cc-mode-help@m.gmane.org; Fri, 17 Feb 2006 08:58:03 +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 BC2BC160CE; Thu, 16 Feb 2006 23:58:01 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1FA0Uf-0001eg-QF for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 23:57: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 1FA0Uf-000661-MO for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 23:57:34 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1FA0UZ-0000po-4d for bug-cc-mode@gnu.org; Fri, 17 Feb 2006 02:57:27 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1FA0Zo-0007hW-Nl for bug-cc-mode@gnu.org; Fri, 17 Feb 2006 03:02:55 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1FA0Zo-0007hI-2O for bug-cc-mode@gnu.org; Fri, 17 Feb 2006 03:02:52 -0500 Original-Received: (qmail invoked by alias); 17 Feb 2006 07:57:20 -0000 Original-Received: from N895P016.adsl.highway.telekom.at (EHLO [62.47.55.208]) [62.47.55.208] by mail.gmx.net (mp004) with SMTP; 17 Feb 2006 08:57:20 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Stefan Monnier In-Reply-To: <87slqjcorr.fsf-monnier+emacs@gnu.org> X-Y-GMX-Trusted: 0 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: Fri, 17 Feb 2006 08:48:45 +0100 Xref: news.gmane.org gmane.emacs.cc-mode.general:3042 gmane.emacs.devel:50648 Archived-At: > 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). Text within "<<" ... ">>" would have to keep its multiline property forever. Take: << ... bar ... > "bar" wouldn't be highlighted specially. Insert the closing ">": << ... bar ... >> "bar" would be highlighted specially. Now overwrite "r" by "z": << ... baz ... >> Who'd be responsible for highlighting "baz" specially? Also, checking for the presence of "<<" ... ">>" round window-start just when the buffer changes is insufficient. You have to check also whenever you jump to an arbitrary buffer position preceded by unfontified text, scroll the window back into unfontified text, or change your window configuration - lazy-lock.el knows the according hooks. > 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. With jit-lock and the "first line" before window-start that wouldn't change a thing. `font-lock-fontify-syntactically-region' and `font-lock-fontify-keywords-region' have identic arguments - at least when called by `font-lock-default-fontify-region'. Calling `font-lock-fontify-syntactically-region' from (min jit-lock-context-unfontify-pos beg) instead of `beg' would fix this but you won't get rid of a multiline property here either. And, when you insert the contents of an entire file into the current buffer you would have to fontify them all before you were able to continue working. ------------------------------------------------------- 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