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: Thu, 10 Mar 2005 17:59:26 -0500 Message-ID: References: <5bk6of409s.fsf@lister.roxen.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110496285 17158 80.91.229.2 (10 Mar 2005 23:11:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 10 Mar 2005 23:11:25 +0000 (UTC) Cc: Alan Mackenzie , emacs-devel@gnu.org, Richard Stallman Original-X-From: cc-mode-help-admin@lists.sourceforge.net Fri Mar 11 00:11:23 2005 Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D9Wfr-0003WR-4s for sf-cc-mode-help@m.gmane.org; Fri, 11 Mar 2005 00:02:36 +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 893E9162C1; Thu, 10 Mar 2005 15:02:32 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1D9WfV-0002Nx-LN for cc-mode-help@lists.sourceforge.net; Thu, 10 Mar 2005 15:02:13 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by sc8-sf-mx2.sourceforge.net with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41) id 1D9WfU-0005gQ-A6 for cc-mode-help@lists.sourceforge.net; Thu, 10 Mar 2005 15:02:13 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D9WfS-0007bo-Mq for bug-cc-mode@gnu.org; Thu, 10 Mar 2005 18:02:10 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1D9Wcz-0005zS-PI for bug-cc-mode@gnu.org; Thu, 10 Mar 2005 17:59:38 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D9Wcz-0005z7-Ch; Thu, 10 Mar 2005 17:59:37 -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 74967340017; Thu, 10 Mar 2005 17:59:31 -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 D42CD4AC28B; Thu, 10 Mar 2005 17:59:26 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id B19A64BD52; Thu, 10 Mar 2005 17:59:26 -0500 (EST) Original-To: bug-cc-mode@gnu.org In-Reply-To: <5bk6of409s.fsf@lister.roxen.com> (Martin Stjernholm's message of "Thu, 10 Mar 2005 23:13:51 +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.821, requis 5, autolearn=not spam, AWL 0.08, BAYES_00 -4.90) X-Spam-Status: No, hits=-2.0 required=5.0 tests=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.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with . 0.0 SF_CHICKENPOX_SLASH BODY: Text interparsed with / 0.0 SF_CHICKENPOX_MINUS BODY: Text interparsed with - 0.0 SF_CHICKENPOX_BRACKET_OPEN BODY: Text interparsed with [ 0.0 SF_CHICKENPOX_AT BODY: Text interparsed with @ 0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with ' -0.0 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: Thu, 10 Mar 2005 17:59:26 -0500 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:2279 gmane.emacs.devel:34438 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34438 >> - why can't they use the font-lock-multiline property? >> - why can't they use the jit-lock-defer-multiline property? > One argument for a hook alternative to these things is that it might > not be efficient/convenient to spread text properties all over the > place: You misunderstood: I'm not particularly happy about either of the *-multiline text-properties. I wrote both of them, but neither of them is satisfactory, really. But I want to better understand the limitations and strength of each approach before adding a new hook. 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: The problem is: how to get font-lock to refontify s[foo]{ bar }x when it's changed to s[foo]{ bar }xe since the first `bar' should be treated like a string whereas the second should be treated like code. 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. OTOH using something like Alan's hook, I'm stuck because if I see "}xe" I don't even know if I'm within code, or within a string, let along if the } happens to be closing the second arg of an `s' operation. It can be done, of course, but it's a fair bit of redundant work especially since you have to make sure it's not too slow in the "usual" case (where the hook shouldn't do anything). I suspect that in the case mentioned in the subject the problem might be similar. > o Text properties stay behind when the buffer changes, and so they > might become invalid. Adding code to correctly remove them before > that can be tricky. font-lock (and jit-lock) should take care of that for you. > o Putting text properties in place and handling stickiness etc > properly is decidedly more complex than just returning a region > from a hook. I haven't seen code that bothers with stickiness when handling *-multiline, so it doesn't seem complex. I do agree that for the awk-mode case, Alan's hook is probably one of the most straightforward solution. But I must also say I'm not convinced by the resulting behavior in awk-mode (or c-mode for that matter). After all, it catches the problem of forgetting a \, so the warning face should be applied to the \n char where the \ is missing, not to the opening/closing quote. This would tie in with another "todo" feature: provide font-lock-keywords specific to a particular syntatic context: you could thus have separate keywords highlighted in comments and in strings. Quite handy for Javadoc thingies. Stefan ------------------------------------------------------- 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