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: Thu, 16 Feb 2006 09:56:45 +0100 Message-ID: <43F43E4D.4080206@gmx.at> References: 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 1140081014 4194 80.91.229.2 (16 Feb 2006 09:10:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2006 09:10:14 +0000 (UTC) Cc: Stefan Monnier , bug-cc-mode@gnu.org, Ralf Angeli , rms@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Thu Feb 16 10:10:10 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 1F9f9L-0002fJ-KH for sf-cc-mode-help@m.gmane.org; Thu, 16 Feb 2006 10:10:08 +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 DC32C13C08; Thu, 16 Feb 2006 01:10:06 -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 1F9f8i-0007vO-QD for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 01:09:28 -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 1F9f8i-0000h8-A6 for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 01:09:28 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9f8h-0001Le-0P for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 04:09:27 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9fDj-00085J-Ny for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 04:14:42 -0500 Original-Received: from [213.165.64.21] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1F9fDj-000857-5I for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 04:14:39 -0500 Original-Received: (qmail invoked by alias); 16 Feb 2006 09:09:21 -0000 Original-Received: from N824P004.adsl.highway.telekom.at (EHLO [62.47.46.228]) [62.47.46.228] by mail.gmx.net (mp018) with SMTP; 16 Feb 2006 10:09:21 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Alan Mackenzie In-Reply-To: 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: Thu, 16 Feb 2006 09:56:45 +0100 Xref: news.gmane.org gmane.emacs.cc-mode.general:3020 gmane.emacs.devel:50604 Archived-At: > There's the macro combine-after-change-calls to mitigate this. ... > Surely it would be possible to arrange for this searching to be done only > when one of these delimiters is inserted or deleted? > > In a before-change function, you check whether or not a change is `combine-after-change-calls' won't combine anything when `before-change-functions' is non-nil. > happening around a ">>", ">", "<" or "<<", and record this in some > variables. In the after-change you see if a delimiter has actually been > inserted or deleted. Only then need you search. Since this searching > will be done only rarely, you probably don't need to worry about > searching even the entire buffer. When you fill text you would have to (1) scan every line for occurrences of these strings in `before-change-functions' and record these occurrences somehow (maybe using markers), (2) apply the change for that line, and (3) scan the line again for matching occurrences of these strings in `after-change-functions' (and maybe release the markers). All this in the presence of some LaTeX syntax specific math context whose bounds you have to recalculate for every single change too. And, what's worse, all this is completely useless since filling shouldn't affect fontification anyway. ------------------------------------------------------- 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