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 10:07:19 +0100 Message-ID: <43F440C7.8010805@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 1140081023 4224 80.91.229.2 (16 Feb 2006 09:10:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2006 09:10:23 +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 10:10:19 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 1F9f9N-0002fz-J5 for sf-cc-mode-help@m.gmane.org; Thu, 16 Feb 2006 10:10:09 +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 C857213C1E; Thu, 16 Feb 2006 01:10:08 -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 1F9f8m-0007vv-QX for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 01:09:32 -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 1F9f8m-0000iQ-A3 for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 01:09:32 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9f8k-0001MG-Sq for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 04:09:30 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9fDn-00086A-Mw for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 04:14:46 -0500 Original-Received: from [213.165.64.21] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1F9fDn-00085w-4T for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 04:14:43 -0500 Original-Received: (qmail invoked by alias); 16 Feb 2006 09:09:26 -0000 Original-Received: from N824P004.adsl.highway.telekom.at (EHLO [62.47.46.228]) [62.47.46.228] by mail.gmx.net (mp031) with SMTP; 16 Feb 2006 10:09:26 +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 10:07:19 +0100 Xref: news.gmane.org gmane.emacs.cc-mode.general:3023 gmane.emacs.devel:50607 Archived-At: > Why don't you construct a regular expression which would only find a "<<" > which isn't in a maths construct? A regular expressions that knows about syntactic context? > I don't know LaTex, but assuming these > "<<" ">>" pairs can't be nested (is this the case?), you could make this > regexp stop (with "not found") at a second "<<" (not within a maths > thingy). This means when you change a "maths thingy" you have to check for "<<"s and ">>"s that are now in- / outside the thingy as well. > In your font-lock matcher function, you would first go back to a "safe > place", then scan forward for this regexp. Even though the regexp would > be quite intricate, it would still be reasonably fast, even if you end up > scanning to the end of the buffer. That wouldn't be just-in-time any more. > Another idea would be to maintain a list of "<<" ">>" pairs, which > you would update in an after-change-function. Using markers? > I suggest that you font lock only the complete construct "<< ..... >>". > You might want to give an unmated "<<" or ">>" font-lock-warning-face > until the user completes the construct. That works efficiently for syntactically fontified text like comments or strings. In the present case it's yet another complication - typing ">>" might cause searching from bob till point. ------------------------------------------------------- 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