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: Wed, 15 Feb 2006 15:20:40 +0100 Message-ID: <43F338B8.8050505@gmx.at> References: <87fymod0dt.fsf-monnier+emacs@gnu.org> <43F18C90.4050205@gmx.at> <87hd71ojgv.fsf-monnier+emacs@gnu.org> <43F239E3.2020707@gmx.at> <87vevhmzbx.fsf-monnier+emacs@gnu.org> <43F2FFAC.5030100@gmx.at> 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 1140013276 11993 80.91.229.2 (15 Feb 2006 14:21:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Feb 2006 14:21:16 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org, Stefan Monnier , rms@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Wed Feb 15 15:21:13 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 1F9NWH-0000RJ-1i for sf-cc-mode-help@m.gmane.org; Wed, 15 Feb 2006 15:20:37 +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 36FEC88BF5; Wed, 15 Feb 2006 06:20:36 -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 1F9NV5-0004Ca-5p for cc-mode-help@lists.sourceforge.net; Wed, 15 Feb 2006 06:19: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 1F9NV4-0001Dy-JI for cc-mode-help@lists.sourceforge.net; Wed, 15 Feb 2006 06:19:23 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9NV1-0001d8-CJ for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 09:19:19 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9NZs-0000P3-Tp for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 09:24:23 -0500 Original-Received: from [213.165.64.21] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1F9NZs-0000Os-GL for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 09:24:20 -0500 Original-Received: (qmail invoked by alias); 15 Feb 2006 14:19:13 -0000 Original-Received: from M3095P015.adsl.highway.telekom.at (EHLO [88.117.34.207]) [88.117.34.207] by mail.gmx.net (mp002) with SMTP; 15 Feb 2006 15:19:13 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Ralf Angeli In-Reply-To: X-Y-GMX-Trusted: 0 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: Wed, 15 Feb 2006 15:20:40 +0100 Xref: news.gmane.org gmane.emacs.cc-mode.general:3001 gmane.emacs.devel:50566 Archived-At: >>In particular the hook might trigger fontification for regions that are >>not displayed thus defeating the purpose of jit-lock. > > > What alternative is there if fontification of a visible portion of the > buffer depends on text not being displayed? Fontifying text that does not reside near the beginning of a buffer usually always depends on analyzing the syntax of text that is not displayed. In fact, fontification must work independently of whether text is displayed or not. That's, for example, the driving principle of stealth fontification. However, fontification of some region A of a buffer should not depend on whether or how some region B of a buffer has been fontified before (multiline keywords are a notorious exception to this rule). Your proposal - please correct me if I'm wrong - may fontify modified text disregarding whether the text appears in some window or not. That, in principle, defeats the aim of jit-lock to fontify as few text as necessary in order to display it correctly. I don't see anything wrong with jit-fontifiying portions of text around displayed regions if such portions would have to be scanned / searched anyway in order to determine how displayed text shall be fontified. Often a user might want to scroll into such regions sooner or later anyway. If, however, filling or indenting larger regions will have to refontify text regardless of whether the text is displayed anywhere, the overhead might get intrusive. ------------------------------------------------------- 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