From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie 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 19:34:39 +0000 (GMT) Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1140037037 10488 80.91.229.2 (15 Feb 2006 20:57:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Feb 2006 20:57:17 +0000 (UTC) Cc: rms@gnu.org, bug-cc-mode@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Wed Feb 15 21:57:14 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 1F9Ti3-00044h-Kb for sf-cc-mode-help@m.gmane.org; Wed, 15 Feb 2006 21:57:12 +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 8AA1913B48; Wed, 15 Feb 2006 12:57:10 -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 1F9Thk-0007JB-Mc for cc-mode-help@lists.sourceforge.net; Wed, 15 Feb 2006 12:56:52 -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 1F9Thi-0002rq-BF for cc-mode-help@lists.sourceforge.net; Wed, 15 Feb 2006 12:56:52 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9Thc-00077G-EY for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 15:56:44 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9TmU-0005U6-Ez for bug-cc-mode@gnu.org; Wed, 15 Feb 2006 16:01:49 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F9TmS-0005Td-Ix; Wed, 15 Feb 2006 16:01:45 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id TAA00948; Wed, 15 Feb 2006 19:34:40 GMT X-Sender: root@acm.acm Original-To: Ralf Angeli In-Reply-To: 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 19:34:39 +0000 (GMT) Xref: news.gmane.org gmane.emacs.cc-mode.general:3006 gmane.emacs.devel:50577 Archived-At: Hi, Ralf! On Sun, 12 Feb 2006, Ralf Angeli wrote: >The quoted message is from a discussion back in last March regarding >the addition of a hook for extending backwards the region to be >fontified with a hook to be called before >`font-lock-after-change-function'. >* Richard Stallman (2005-03-11) writes: >> This patch to font-lock is exactly the sort of change I was thinking >> of. Could someone please install it, then rename >> before-font-lock-after-change-function to >> font-lock-extend-region-function, and rename >> font-lock-run-before-after-change-hook to font-lock-extend-region? >Apparently the hook hasn't been added yet. Is it still planned to add >it? >The reason I am asking this is that I am currently wrecking my brain >about how to make font locking for LaTeX buffers controlled by AUCTeX >more robust. On a regular basis we are getting reports about font >locking of multiline constructs failing, thereby spilling color all >over the buffer and/or slowing down editing quite severly. (We are >using `font-lock-multiline' for fontification of multiline >constructs.) This mainly happens with text which is erroneously >identified as the start of a multiline construct but has no matching >closing tag. The last report we got was about "<<" which can be an >opening quotation mark but which may also be used unmatched in some >math constructs. Why don't you construct a regular expression which would only find a "<<" which isn't in a maths construct? 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). 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. Another idea would be to maintain a list of "<<" ">>" pairs, which you would update in an after-change-function. >An idea for making font locking more robust in this respect might be >to desist from coloring the rest of the buffer in case of an unmatched >opening tag, i.e. to leave it alone if a matching closing tag cannot >be found in an arbitrarily large region after the opening tag. 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 would mean fontification will only be applied as soon as the >closing tag is typed. For that to work, however, I'd have to look >backwards for an opening tag which could be done with a hook like the >one proposed above. >Ralf -- Alan Mackenzie (Munich, Germany) ------------------------------------------------------- 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