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: font-lock-extend-region-function: Final refinements. Date: Fri, 4 Aug 2006 09:55:36 +0100 Message-ID: <20060804085536.GA1107@muc.de> References: <20060803163040.GC1282@muc.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1154678440 757 80.91.229.2 (4 Aug 2006 08:00:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 4 Aug 2006 08:00:40 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 04 10:00:35 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 1G8ubb-0005CX-OH for ged-emacs-devel@m.gmane.org; Fri, 04 Aug 2006 10:00:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G8ubb-000314-BU for ged-emacs-devel@m.gmane.org; Fri, 04 Aug 2006 04:00:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G8ubP-00030z-Ir for emacs-devel@gnu.org; Fri, 04 Aug 2006 04:00:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G8ubN-00030n-Qu for emacs-devel@gnu.org; Fri, 04 Aug 2006 04:00:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G8ubN-00030k-MD for emacs-devel@gnu.org; Fri, 04 Aug 2006 04:00:13 -0400 Original-Received: from [193.149.48.1] (helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G8uet-0004iT-CO for emacs-devel@gnu.org; Fri, 04 Aug 2006 04:03:51 -0400 Original-Received: (qmail 69461 invoked from network); 4 Aug 2006 08:00:06 -0000 Original-Received: from acm.muc.de (HELO localhost.localdomain) (Debian-exim@193.149.49.134) by mail.muc.de with SMTP; 4 Aug 2006 08:00:06 -0000 Original-Received: from acm by localhost.localdomain with local (Exim 4.50) id 1G8vSy-0000aR-T2; Fri, 04 Aug 2006 09:55:36 +0100 Original-To: Stefan Monnier Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i 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:58080 Archived-At: Morning, Stefan! [ cc: emacs-devel added.] On Thu, Aug 03, 2006 at 02:43:23PM -0400, Stefan Monnier wrote: > > One small point - there are slightly different mechanisms in > > jit-lock-after-change and font-lock-after-change-function for > > extending the region. Is there a reason for this? > Yes. > Basically here is what happens in f-l-after-change: > A1 - obey f-l-extend-after-change-function. > Here is what happens in j-l-after-change (via > f-l-extend-jit-lock-region-after-change): > B1 - obey f-l-extend-after-change-function. > B2 - obey font-lock-multiline (just once: no looping). > B3 - round up to whole lines. > - A1 == B1. That's not quite true. B1 uses j-l-after-change-extend-region-functions, which has the same purpose as f-l-extend-after-change-function, but a different calling convention. I can't see any reason why these two need to be different - it seems to be an unnecessary complication. font-lock-extend-region-functions uses yet a third calling convention, although what it is doing is almost (but not quite) the same as A1 and B1. Could we not decide on the one or the other calling convention and use it in both places? At the very least, could we not use just one pair of variables rather than both `font-lock-beg/end' and `jit-lock-start/end'? With both pairs of variables, I can foresee lots of major mode code ugliness like this: (set (if from-jit-a-c 'jit-lock-start 'font-lock-beg) construct-start) > - B3 is only present so as to avoid double redisplay. I.e. it's not needed > for correctness. It could/should be replaced by the same code as what is > done in f-l-default-fontify-region, except that would be potentially > too costly. > - B2 OTOH is important: it's the main way font-lock-multiline works: it > marks the part of the text that will need to be refontified before being > redisplayed. It does not care about it being refontified atomically, > which is why it does not loop. > Why is there no corresponding A2? Because f-l-after-change ends up > calling f-l-fontify-region where f-l-multiline is obeyed anyway. I've thought this over for some time, and I'm convinced that's all right. > Note that the use of f-l-multiline in f-l-fontify-region is not > reliable: it's basically using it to do /identification/ which is > known not be reliable, but experience shows that it can be useful to > do it, so that if a piece of text does get identified somehow at some > point, its multilineness will usually be preserved. I can't see that it's unreliable, but I'll take your word for it. The lack of f-l-multiline (or like-minded hook function) is what fouled up the highlighting in the example I gave a day or two ago, after 500 bytes: [This one: #ifndef VMS /* VMS hates multi-line '#if's */ # if !defined(ibm032) && \ !defined(__convex__) && \ !(defined(vax) && !defined(ultrix)) && \ ... ... ] I agree with you that f-l-multiline needs to be checked in f-l-fontify-region. > Stefan -- Alan.