From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Last steps for pretesting (font-lock-extend-region-function) Date: Thu, 20 Apr 2006 16:58:44 -0400 Message-ID: <87odywou9w.fsf-monnier+emacs@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1145566758 3781 80.91.229.2 (20 Apr 2006 20:59:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2006 20:59:18 +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 22:59:16 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 1FWgEz-0008DY-S2 for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 22:59:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWgEz-00006u-EE for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 16:59:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWgEl-0008W4-II for emacs-devel@gnu.org; Thu, 20 Apr 2006 16:58:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWgEk-0008UN-6Y for emacs-devel@gnu.org; Thu, 20 Apr 2006 16:58:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWgEj-0008UF-Vu for emacs-devel@gnu.org; Thu, 20 Apr 2006 16:58:50 -0400 Original-Received: from [209.226.175.54] (helo=tomts10-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWgG5-0003g8-8b; Thu, 20 Apr 2006 17:00:13 -0400 Original-Received: from alfajor ([70.53.192.213]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060420205844.ZMQB20622.tomts10-srv.bellnexxia.net@alfajor>; Thu, 20 Apr 2006 16:58:44 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id 40A94D91AB; Thu, 20 Apr 2006 16:58:44 -0400 (EDT) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Thu, 20 Apr 2006 18:12:52 +0000 (GMT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:53158 Archived-At: >> 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. IIRC part (i) needs more than an after-change-function: it also needs a before-change-function. And (again IIRC) it's the part that can already be solved by placing (from one of the font-lock-keywords rules) a font-lock-multiline property. Basically it's the part that makes sure that if a multiline element loses its multiline status, the whole (previously atomic) text gets properly refreshed. I find it very hard to believe that b-f-c + a-f-c ends up being as efficient/elegant/robust as placing a font-lock-multiline property. In all likely hood, adding the font-lock-multiline property is a matter of adding a single line of code at the right place (the place where you fontify the corresponding multiline entity). Here is the problems I see with your proposal: - an `extend-region' hook in font-lock-fontify-region is needed - the font-lock-multiline property should be enough in all cases to make it unnecessary to use an after-change-function hook. - adding an after-change-function hook additionally to a font-lock-fontify-region hook means making font-lock that much more complex to use and maintain, especially since that after-change-function basically can't be used without also adding a before-change-function. - an after-change-function is expensive, and even more when it comes bundled with a before-change-function, and even more so when compared to code that's only run during font-locking. Stefan