From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ralf Angeli Newsgroups: 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 23:58:49 +0100 Organization: nil Message-ID: References: <87fymod0dt.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1139788786 11288 80.91.229.2 (12 Feb 2006 23:59:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2006 23:59:46 +0000 (UTC) Cc: bug-cc-mode@gnu.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 13 00:59:43 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F8R80-0001G2-B5 for ged-emacs-devel@m.gmane.org; Mon, 13 Feb 2006 00:59:41 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F8R7z-0000UB-RP for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2006 18:59:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F8R7o-0000Tw-53 for emacs-devel@gnu.org; Sun, 12 Feb 2006 18:59:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F8R7m-0000Tk-Ft for emacs-devel@gnu.org; Sun, 12 Feb 2006 18:59:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F8R7m-0000Th-BT for emacs-devel@gnu.org; Sun, 12 Feb 2006 18:59:26 -0500 Original-Received: from [134.96.7.25] (helo=triton.rz.uni-saarland.de) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F8RBz-0002qE-G1; Sun, 12 Feb 2006 19:03:47 -0500 Original-Received: from iwi-gate.iwi.uni-sb.de (iwi-gate.iwi.uni-saarland.de [134.96.72.13]) by triton.rz.uni-saarland.de (8.12.10/8.12.10) with ESMTP id k1CNx6bO10329396; Mon, 13 Feb 2006 00:59:06 +0100 (CET) Original-Received: from [134.96.72.191] (helo=iwi191.iwi.uni-sb.de) by iwi-gate.iwi.uni-sb.de with esmtp (Exim 4.53 (FreeBSD)) id 1F8R7B-000Bg3-Hg; Mon, 13 Feb 2006 00:58:49 +0100 Original-Received: from angeli by iwi191.iwi.uni-sb.de with local (Exim 4.60) (envelope-from ) id 1F8QB7-000625-Ow; Sun, 12 Feb 2006 23:58:49 +0100 Original-To: Stefan Monnier In-Reply-To: <87fymod0dt.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sun, 12 Feb 2006 11:20:23 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-IWi-MailScanner-Information: Please contact the ISP for more information X-IWi-MailScanner: Found to be clean X-IWi-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5, autolearn=disabled) X-MailScanner-From: angeli@iwi.uni-sb.de X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.1 (triton.rz.uni-saarland.de [134.96.7.25]); Mon, 13 Feb 2006 00:59:06 +0100 (CET) X-AntiVirus: checked by AntiVir Milter (version: 1.1.1-9; AVE: 6.33.0.31; VDF: 6.33.0.229; host: AntiVir2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50431 Archived-At: * Stefan Monnier (2006-02-12) 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? > > 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. You can find the patch at . >> 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? Currently a function is used as matcher in `font-lock-keywords' for this functionality. It basically operates like this: (catch 'match (while (re-search-forward "<<" limit t) (let ((beg (match-beginning 0))) (search-forward ">>" limit 'move) (store-match-data (list beg (point))) (throw 'match t)))) That means, search for an opening tag and if you find one search for the closing tag till `limit'. If an opening tag was found, set the match to the region from the opening tag to the closing tag, or `limit' if none was found. What I'd like to use instead is this: (catch 'match (while (re-search-forward "<<" limit t) (let* ((beg (match-beginning 0)) (after-beg (match-end 0)) (point-of-surrender (+ beg 1000))) (search-forward ">>" point-of-surrender 'move) (if (= (point) point-of-surrender) (progn (goto-char after-beg) (store-match-data (list after-beg after-beg))) (store-match-data (list beg (point)))) (throw 'match t)))))) That means, search for an opening tag and if one is found search for the closing tag till an arbitrarily large region after the opening tag (1000 characters large in the code above). If no closing tag is found, set an empty match; if one is found, set the match from the opening to the closing tag. With the matcher function above text in quotation marks won't be fontified when I start typing stuff like "<>" was detected after typing it, I'd search backwards in an arbitrarily large region for a starting "<<" quotation mark and extend the region to be fontified backwards till that point. Now font-lock will find both the opening and closing quotation marks and fontify the enclosed text. -- Ralf