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: Mon, 13 Feb 2006 17:10:36 -0500 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 1139868673 17597 80.91.229.2 (13 Feb 2006 22:11:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 13 Feb 2006 22:11:13 +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 Mon Feb 13 23:11:09 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 1F8luU-0003zh-1F for sf-cc-mode-help@m.gmane.org; Mon, 13 Feb 2006 23:11:06 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id 4345A88D16; Mon, 13 Feb 2006 14:11:05 -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 1F8luC-0002nU-6P for cc-mode-help@lists.sourceforge.net; Mon, 13 Feb 2006 14:10:48 -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 1F8luA-0001Ld-BV for cc-mode-help@lists.sourceforge.net; Mon, 13 Feb 2006 14:10:48 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F8lu8-0003PA-Un for bug-cc-mode@gnu.org; Mon, 13 Feb 2006 17:10:44 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F8lyc-0005zq-IH for bug-cc-mode@gnu.org; Mon, 13 Feb 2006 17:15:25 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F8lyc-0005ze-9p; Mon, 13 Feb 2006 17:15:22 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 6FD612CE990; Mon, 13 Feb 2006 17:10:40 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id D42744AC1D4; Mon, 13 Feb 2006 17:10:36 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id B64A571450; Mon, 13 Feb 2006 17:10:36 -0500 (EST) Original-To: Ralf Angeli In-Reply-To: (Ralf Angeli's message of "Sun, 12 Feb 2006 23:58:49 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.854, requis 5, autolearn=not spam, AWL 0.05, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca 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: Mon, 13 Feb 2006 17:10:36 -0500 Xref: news.gmane.org gmane.emacs.cc-mode.general:2982 gmane.emacs.devel:50489 Archived-At: > 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)))) I.e. equivalent to "<<\\(.\\|\n\\)*?\\(>>\\)?". > 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 "< no closing quotation mark. Now if the closing quotation mark is > entered a few lines below the line containing the opening quotation > mark, font locking won't see the opening quotation mark and the > multiline quotation won't be fontified. Indeed. You can use contextual refontification, tho: (if jit-lock-context-unfontify-pos (setq jit-lock-context-unfontify-pos (min jit-lock-context-unfontify-pos (re-search-backward "<<" limit t)))) it's specific to jit-lock, tho. Also it will not refontify immediately but only after jit-lock-contex-time. I'd consider it a feature, but others may disagree. Finally, the above code is naive: you'd have to make sure it's only used when refontification will indeed make a difference, otherwise the code could be triggered again and the context refontification could repeat over and over again. I like the idea behind your before-font-lock-after-change-function, except that I'd want it to be in font-lock-default-fontify-region. I.e. it should then be possible to remove mention of font-lock-multiline from font-lock-default-fontify-region by moving it to this new hook (which we could call font-lock-fontify-extend-region-functions). 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