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: Tue, 14 Feb 2006 09:49:46 +0100 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 1139907199 2507 80.91.229.2 (14 Feb 2006 08:53:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2006 08:53:19 +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 Tue Feb 14 09:53:15 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 1F8vvt-0004W8-AK for ged-emacs-devel@m.gmane.org; Tue, 14 Feb 2006 09:53:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F8vvs-0008Cl-Me for ged-emacs-devel@m.gmane.org; Tue, 14 Feb 2006 03:53:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F8vtL-0005xb-10 for emacs-devel@gnu.org; Tue, 14 Feb 2006 03:50:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F8vtG-0005uz-PK for emacs-devel@gnu.org; Tue, 14 Feb 2006 03:50:34 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F8vtE-0005uP-OD for emacs-devel@gnu.org; Tue, 14 Feb 2006 03:50:30 -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 1F8vxU-0003hR-KC; Tue, 14 Feb 2006 03:54:53 -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 k1E8nqbO10417464; Tue, 14 Feb 2006 09:49:52 +0100 (CET) Original-Received: from [134.96.72.190] (helo=neutrino.iwi.uni-sb.de) by iwi-gate.iwi.uni-sb.de with esmtp (Exim 4.53 (FreeBSD)) id 1F8vsR-000GId-2U; Tue, 14 Feb 2006 09:49:39 +0100 Original-Received: from angeli by neutrino.iwi.uni-sb.de with local (Exim 4.60) (envelope-from ) id 1F8vsY-0002mk-LV; Tue, 14 Feb 2006 09:49:46 +0100 Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Mon, 13 Feb 2006 17:10:36 -0500") 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]); Tue, 14 Feb 2006 09:49:52 +0100 (CET) X-AntiVirus: checked by AntiVir Milter (version: 1.1.1-9; AVE: 6.33.0.31; VDF: 6.33.0.233; 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:50518 Archived-At: * Stefan Monnier (2006-02-13) writes: >> 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)))) Ouch. Pasting the code into a wterm messed up indentation pretty badly. )c: > I.e. equivalent to "<<\\(.\\|\n\\)*?\\(>>\\)?". The function actually used in AUCTeX does a bit more. For example it checks if a face for verbatim content is present and does not set a match in such a case. >> 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. Hm, I would not like leaving people who disabled jit-lock out in the cold. So the hook is probably a better alternative. But thanks for that hint anyway. > Also it will not refontify immediately but only after jit-lock-contex-time. > I'd consider it a feature, but others may disagree. I am tempted to disagree but maybe this is a case of getting used to it. > I like the idea behind your before-font-lock-after-change-function, except Uh, Alan Mackenzie is the originator of this proposal, not me. (c: > 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). Hm, how would it be possible to detect closing tags in this case? Maybe with an initial search for these tags across the region to be fontified. Or on a case by case basis for every closing tag which is encountered during fontication of the region? This would be rather inefficient compared to using a hook to be called before `font-lock-after-change-function'. But maybe you are thinking about something completely different. -- Ralf