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: Wed, 19 Apr 2006 22:43:12 +0000 (GMT) Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1145486990 17475 80.91.229.2 (19 Apr 2006 22:49:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 Apr 2006 22:49:50 +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 00:49:46 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 1FWLUT-0005JI-2r for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 00:49:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWLUS-00014U-M3 for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2006 18:49:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWLTt-0000uP-9j for emacs-devel@gnu.org; Wed, 19 Apr 2006 18:49:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWLTs-0000tz-E2 for emacs-devel@gnu.org; Wed, 19 Apr 2006 18:49:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWLTs-0000tr-6s for emacs-devel@gnu.org; Wed, 19 Apr 2006 18:49:04 -0400 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWLV2-0002hp-Pk; Wed, 19 Apr 2006 18:50:17 -0400 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id WAA00351; Wed, 19 Apr 2006 22:43:14 GMT X-Sender: root@acm.acm Original-To: Stefan Monnier In-Reply-To: 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:53112 Archived-At: Evening, Stefan! On Wed, 19 Apr 2006, Stefan Monnier wrote: >> (ii) Writing font-lock-expand-region functions, one for CC Mode as a >> whole (to replace (setq font-lock-lines-before 2)) and one for AWK Mode >> (to replace the advising of the Font Lock after-change functions). >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. Please keep Font Lock working equivalently with and without JIT switched on. Edebugging through font-lock-fontify-region (for debugging a mode's font lock settings) is a nightmare when JIT is enabled. 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. The third parameter (OLD-LEN) gets bound to nil in the new case. In either case the extend-region function is entitled to return nil. My AWK extend region function would then look like this: (defun c-awk-font-lock-extend-region (beg end old-len) (cons (c-awk-beginning-of-logical-line beg) (if old-len ;; From an after-change-function (c-awk-end-of-change-region beg end old-len) ;; From a fontifying routine (c-awk-end-of-logical-line end)))) >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). >.... 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. I'm convinced that either approach would be robust (hey, we're competent hackers ;-). 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. > Stefan -- Alan.