From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Last steps for pretesting (font-lock-extend-region-function) Date: Thu, 20 Apr 2006 18:12:52 +0000 (GMT) Message-ID: References: <87k69kqh7o.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 1145556500 805 80.91.229.2 (20 Apr 2006 18:08:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2006 18:08:20 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 20 20:08:14 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 1FWdZd-00021g-KK for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 20:08:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWdZd-0008EG-4n for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 14:08:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWdZS-0008EA-Aw for emacs-devel@gnu.org; Thu, 20 Apr 2006 14:08:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWdZP-0008Dy-Vj for emacs-devel@gnu.org; Thu, 20 Apr 2006 14:08:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWdZP-0008Dv-PR for emacs-devel@gnu.org; Thu, 20 Apr 2006 14:07:59 -0400 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWdal-0006Oh-2S; Thu, 20 Apr 2006 14:09:24 -0400 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id SAA00465; Thu, 20 Apr 2006 18:12:53 GMT X-Sender: root@acm.acm Original-To: Stefan Monnier In-Reply-To: <87k69kqh7o.fsf-monnier+emacs@gnu.org> 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:53148 Archived-At: Hi, Stefan! On Thu, 20 Apr 2006, Stefan Monnier wrote: >>> BTW, I still intend to move font-lock-extend-region-function from >>> after-change-functions to font-lock-fontify-region (or maybe even >>> jit-lock-fontify). >> That would radically change the meaning of the function. >Of course. >> How about the following compromise? font-lock-extend-region-function >> should get called BOTH in the two after-change functions AND in >> jit-lock-fontify-now and font-lock-default-fontify-region. >No, my problem is specifically with calling it from >after-change-functions. You mean in calling it ONLY from a-c-f? Or from calling it in after-change-functions at all? >>> So if you really manage to use the current >>> font-lock-extend-region-function (called from after-change-functions) >>> in a way that's robust, efficient, ..... >> So far, yes (except, perhaps, for the need of an extend-region >> function in j-l-f-n and f-l-d-f-r). >So your code needs extend-region both in a-c-f and in f-l-d-f-r ? Yes. The region needs extending in two distinct circumstances: (i) In after-change, to determine the entire region which needs refontifying; (ii) In jit-lock-fontify-now, to ensure that each chunk starts and stops at a "safe place". These are logically disjoint. But it seems that the major mode code to do each of them is so similar, that we might as well just have a single function, font-lock-extend-region-function, called in two different ways. >>> .... and can't be done as efficiently/elegantly/robustly with a hook >>> in font-lock-fontify-region (or with the font-lock-multiline >>> property), please scream. >> AAAAAAAAARRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!! >> I don't think we're going to agree on the relative elegance of >> font-lock-extend-region-function vs. font-lock-multiline. I think >> that the former is more elegant than the latter, and you think the >> latter is the more elegant. >Of course, we don't have to agree on every detail. :-) >> I'm convinced that either approach would be robust (hey, we're competent >> hackers ;-). >I'm convinced that only using a-c-f would *not* be robust, no matter how >competent the hacker. I agree with you here. >> However, I think that f-l-extend-region-function can be done more >> efficiently by the major mode maintainer, in the sense that it will >> require less time and effort reading manuals, reading fine source, and >> coding. >more efficiently than what? More efficiently than setting font-lock-multiline text properties. > Stefan -- Alan.