From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Martin Stjernholm 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, 13 Mar 2005 17:19:21 +0100 Message-ID: <5bu0nfplh2.fsf@lister.roxen.com> References: <5bk6of409s.fsf@lister.roxen.com> Reply-To: bug-cc-mode@gnu.org NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110730957 24276 80.91.229.2 (13 Mar 2005 16:22:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 13 Mar 2005 16:22:37 +0000 (UTC) Cc: bug-cc-mode@gnu.org, Alan Mackenzie , emacs-devel@gnu.org, Richard Stallman Original-X-From: cc-mode-help-admin@lists.sourceforge.net Sun Mar 13 17:22:36 2005 Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DAVq2-000226-Ig for sf-cc-mode-help@m.gmane.org; Sun, 13 Mar 2005 17:21:11 +0100 Original-Received: from projects.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 8B94812C87; Sun, 13 Mar 2005 08:21:33 -0800 (PST) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1DAVqC-0001N9-TO for cc-mode-help@lists.sourceforge.net; Sun, 13 Mar 2005 08:21:20 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by sc8-sf-mx1.sourceforge.net with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41) id 1DAVqB-0002Pr-80 for cc-mode-help@lists.sourceforge.net; Sun, 13 Mar 2005 08:21:20 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DAVq7-0008IK-Q5 for bug-cc-mode@gnu.org; Sun, 13 Mar 2005 11:21:15 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1DAVoQ-0006My-Os for bug-cc-mode@gnu.org; Sun, 13 Mar 2005 11:19:31 -0500 Original-Received: from [212.247.28.43] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DAVoQ-0006Mu-7a; Sun, 13 Mar 2005 11:19:30 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 258DC993E; Sun, 13 Mar 2005 17:19:30 +0100 (MET) Original-Received: from localhost (localhost [127.0.0.1]) by mail.roxen.com (Postfix) with ESMTP id C688E99E2; Sun, 13 Mar 2005 17:19:25 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [212.247.28.136]) by mail.roxen.com (Postfix) with ESMTP id 3D00E993E; Sun, 13 Mar 2005 17:19:22 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1DAVoH-0003Ry-00; Sun, 13 Mar 2005 17:19:21 +0100 Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Thu, 10 Mar 2005 17:59:26 -0500") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/20.7 (gnu/linux) X-Virus-Scanned: by amavisd 0.1 X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Score: 0.1 (/) 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 0.1 AWL AWL: From: address is in the auto white-list 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, 13 Mar 2005 17:19:21 +0100 X-MailScanner-From: cc-mode-help-admin@lists.sourceforge.net X-MailScanner-To: sf-cc-mode-help@m.gmane.org Xref: news.gmane.org gmane.emacs.cc-mode.general:2296 gmane.emacs.devel:34545 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34545 Stefan Monnier wrote: > When I added the jit-lock-defer-multiline property (mostly for perl-mode), > I first considered adding a hook somewhat like Alan's but it turns out that > it's pretty damn difficult to write this hook: Indeed it is. > The problem is: how to get font-lock to refontify > > s[foo]{ > bar > }x /.../ > Now, when I'm in the middle of font-locking, I've done the work of figuring > out that I'm in an s/foo/bar/ expression and I can easily add > a text-property on the whole thing. That doesn't work very well while the thing is entered, does it? First you see "s[foo]{" while it's being entered, then you see the next line " bar", and lastly "}x". Your patterns will never see the whole construct at once. (They will however see the buffer end, or even worse some completely unrelated code that happen to be on the following lines and which might confuse them.) A text property can help if you can recognize the construct from the first line only, but then you'll have to make another pattern that matches the "}" and contains logic to extend the property put in place by the pattern matching the first line. Another problem is that the "bar" part can get arbitrarily large if it's code, in which case it becomes a performance problem to put a property on it to refontify the whole thing. Another case to consider is that the intervening code can contain nested constructs of the same sort. (I'm not saying it's so in Perl - I'm extending the discussion to the general case.) If the construct can't be recognized from the first line alone, which might very well happen for a C-like declaration, then I see no choice but to have a function that can find the start when the last line is entered. That function can of course use various properties put in place by the major mode to speed up its work. (CC Mode, for instance, already has some internal properties to cache interesting syntactic positions, and I'm thinking about extending that approach a lot.) > I haven't seen code that bothers with stickiness when handling > *-multiline, so it doesn't seem complex. It's still more complex to understand and use text properties at all than to just return a region, especially if one wants the code to work in the two major emacs flavors which have completely different interfaces in this area. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click