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 11:17:16 +0100 Message-ID: <43F2FFAC.5030100@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> 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 1139998847 27331 80.91.229.2 (15 Feb 2006 10:20:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Feb 2006 10:20:47 +0000 (UTC) Cc: bug-cc-mode@gnu.org, Ralf Angeli , rms@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Wed Feb 15 11:20:39 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 1F9Jlg-0006Bo-4A for sf-cc-mode-help@m.gmane.org; Wed, 15 Feb 2006 11:20:16 +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 5D52C1276E; Wed, 15 Feb 2006 02:20:15 -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 1F9Jkz-0000mz-1j for cc-mode-help@lists.sourceforge.net; Wed, 15 Feb 2006 02: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 1F9Jkv-0003w6-B8 for cc-mode-help@lists.sourceforge.net; Wed, 15 Feb 2006 02:19:31 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9Jkt-0003Q9-SY for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 05:19:27 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9Jpi-0001hT-HH for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 05:24:29 -0500 Original-Received: from [213.165.64.21] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1F9Jpi-0001hC-2e for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 05:24:26 -0500 Original-Received: (qmail invoked by alias); 15 Feb 2006 10:19:22 -0000 Original-Received: from N946P024.adsl.highway.telekom.at (EHLO [62.47.62.56]) [62.47.62.56] by mail.gmx.net (mp039) with SMTP; 15 Feb 2006 11:19:22 +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: <87vevhmzbx.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: Wed, 15 Feb 2006 11:17:16 +0100 Xref: news.gmane.org gmane.emacs.cc-mode.general:2996 gmane.emacs.devel:50558 Archived-At: > Note, tho, that the 1000-byte search would probably only only happen when > the line has a ">>" on it. ... has or _had_ a ">>" on it. > And it's all very much fast enough for > self-insert-command. It may show up when using auto-repeat for typing characters. > The problem is much more severe when you're running > a command that does many buffer modification and thus runs the hook > many times without intervening user interaction. In particular the hook might trigger fontification for regions that are not displayed thus defeating the purpose of jit-lock. When you indent, fill, delete larger regions you have to search all beginnings and ends of those regions within the 1000 char limit for "<<"s and ">>"s that might have changed. I still believe that an idle timer would be more appropriate here. Have the hook accumulate the bounds of the most recent changes to a buffer. A timed function would scan from some suitable position before the displayed area - this can be some 1000 chars before window-start but I'd prefer something more Archimedean here like the start of a syntactic entity that cannot appear within "<<" ... ">>" - and search for matching "<<" ">>" pairs between that position and the maximum of the last changed position within the displayed area and the next syntactic entity that can't be within "<<" ... ">>". Obviously, this should be done for every window showing that buffer. ------------------------------------------------------- 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