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: font-lock-extend-region Date: Thu, 23 Mar 2006 11:18:12 -0500 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 1143130740 29505 80.91.229.2 (23 Mar 2006 16:19:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 23 Mar 2006 16:19:00 +0000 (UTC) Cc: bug-cc-mode@gnu.org, martin rudalics , Ralf Angeli , "Richard M. Stallman" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 23 17:18:56 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 1FMSWJ-0007YV-Fq for ged-emacs-devel@m.gmane.org; Thu, 23 Mar 2006 17:18:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FMSWJ-0000x4-2y for ged-emacs-devel@m.gmane.org; Thu, 23 Mar 2006 11:18:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FMSW3-0000wE-35 for emacs-devel@gnu.org; Thu, 23 Mar 2006 11:18:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FMSW1-0000vs-Tu for emacs-devel@gnu.org; Thu, 23 Mar 2006 11:18:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FMSW1-0000vp-JN for emacs-devel@gnu.org; Thu, 23 Mar 2006 11:18:25 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FMSWb-0005tZ-Vs; Thu, 23 Mar 2006 11:19:02 -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 1D1C32CF44A; Thu, 23 Mar 2006 11:18:21 -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 DBDA6452A; Thu, 23 Mar 2006 11:18:12 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id BA2FC71516; Thu, 23 Mar 2006 11:18:12 -0500 (EST) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Thu, 23 Mar 2006 15:23:30 +0000 (GMT)") 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=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca 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:52011 Archived-At: > OK. Yes, I think I agree with you now - the font-lock-multiline property > could indeed do this job successfully (that's assuming it can be set on > an arbitrary sequence of characters, not just on entire lines). This assumption is valid. Actually,the exact chars on which the font-lock-multiline property is added is something important (e.g. you'd have to include the \n after the \\). > It is marginally less good than f-l-e-r-function in one extreme case: > when the extended after-change region is large, and consists of two > contiguous "atomic" ranges. f-l-multiline would force jit-lock to fontify > this atomically, whilst f-l-e-r-function would allow > jit-lock-extend-chunk-function to fontify it as two chunks. No, jit-lock would not be forced to refontify both chunks atomically at the same time. Remember jit-lock only deals with what needs to be refontified (i.e. point (i) in your earlier email) then chunkifies it. Only font-lock-default-fontify-region cares about atomicity (point (ii) in your earlier email). > I still think that f-l-extend-region-f is a more natural approach - IMAO, > it is easier for a major mode to use. I guess it's a matter of taste rather. Often, you can put the font-lock-multiline property very cheaply at the time you're highlighting the multiline element, so you don't need to do any extra work at all to discover its boundaries. In contrast when using f-l-extend-region-f you may have to re-discover the boundaries that you had found last time you highlighted the element. Furthermore, as you've discovered, if you use f-l-extend-region-f you get into trouble when the time comes to refresh an element that used to be multiline but isn't any more: you have to somehow figure out that it was multiline earlier, then find the boundaries it had, then tell jit-lock that this also needs to be refontified. So you end up needing a before-change-function, and an after-change-function, ... Whereas with font-lock-multiline the problem doesn't even appear because it uses text properties to remember the earlier multilineness of the element. > Whatever we do, I think we are agreed that we need a major-mode supplied > function that will extend a jit-lock chunk (as opposed to an after-change > region). The more I think about it, the less I'm convinced it's worth the trouble. I didn't think hard about the design of font-lock-multiline when I implemented it, but it turns out it works really well for what it's designed to do. >> When the redisplay engine calls jit-lock-function with arg 1055, it has >> already redisplayed all the text until 1054 and changes in the buffer that >> affect text before 1055 will not cause redisplay to restart when >> it finishes. > Ah, got it! Thanks! > Maybe the extension-to-whole-lines needs to stay in jit-lock-fontify-now > (since _something_ has to clear the 'fontified text property), and it has > to stay in f-l-default-f-region (since jit-lock isn't always enabled). > That only leaves the after-change one to take out. Maybe. The above problem to which you replied "Ah, I got it" is the one that's solved in the after-change function, so no: we can't take out the one in after-change-function. Clearing the `fontified' property is not a good justification for the code in jit-lock-fontify-now. I really think this one can go. OTOH I think it'd be good if font-lock could return to jit-lock the extent of the area that was actually refreshed (including extension due to font-lock-multiline), so that jit-lock can clear more of the `fontified' property and avoid some redundant font-locking. Stefan