From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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: Sun, 12 Feb 2006 11:20:23 -0500 Message-ID: <87fymod0dt.fsf-monnier+emacs@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1139761291 24927 80.91.229.2 (12 Feb 2006 16:21:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2006 16:21:31 +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 Sun Feb 12 17:21:24 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 1F8JyL-0005Lr-Ta for sf-cc-mode-help@m.gmane.org; Sun, 12 Feb 2006 17:21:15 +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 1CE8212CDF; Sun, 12 Feb 2006 08:21:13 -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 1F8Jxq-0006vh-02 for cc-mode-help@lists.sourceforge.net; Sun, 12 Feb 2006 08:20:42 -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 1F8Jxo-000536-Uj for cc-mode-help@lists.sourceforge.net; Sun, 12 Feb 2006 08:20:41 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F8Jxg-0006Pf-MM for bug-cc-mode@gnu.org; Sun, 12 Feb 2006 11:20:32 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F8K1s-0006bO-Qf for bug-cc-mode@gnu.org; Sun, 12 Feb 2006 11:24:55 -0500 Original-Received: from [209.226.175.25] (helo=tomts5-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F8K1r-0006b5-Cp; Sun, 12 Feb 2006 11:24:52 -0500 Original-Received: from alfajor ([67.68.216.244]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060212162025.ZXMP18394.tomts5-srv.bellnexxia.net@alfajor>; Sun, 12 Feb 2006 11:20:25 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id 8EE4ED7370; Sun, 12 Feb 2006 11:20:23 -0500 (EST) Original-To: Ralf Angeli In-Reply-To: (Ralf Angeli's message of "Sun, 12 Feb 2006 14:06:49 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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: Sun, 12 Feb 2006 11:20:23 -0500 Xref: news.gmane.org gmane.emacs.cc-mode.general:2974 gmane.emacs.devel:50405 Archived-At: >> 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? I can't find this patch any more. Based on the name, I suppose it's some kind of hook in font-lock-after-change-function, in which case I'd be tempted to suggest to move it to font-lock-fontify-region instead, to reduce the performance impact and make it easier to deal with lazy-lock&jit-lock since these tend to use their own after-change-function. > 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. > 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. 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. I'm not sure how that relates to before-font-lock-after-change-function. Could you describe how you currently font-lock those <<...>> multiline elements and how you'd use before-font-lock-after-change-function to solve the problem? Stefan ------------------------------------------------------- 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