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: Tue, 25 Apr 2006 21:49:46 +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 1146005985 29510 80.91.229.2 (25 Apr 2006 22:59:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2006 22:59:45 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 26 00:59:43 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 1FYWVO-0005uu-9m for ged-emacs-devel@m.gmane.org; Wed, 26 Apr 2006 00:59:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYWVN-0005Cb-Si for ged-emacs-devel@m.gmane.org; Tue, 25 Apr 2006 18:59:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYWSv-0002Vr-LH for emacs-devel@gnu.org; Tue, 25 Apr 2006 18:57:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYWSu-0002VI-Mj for emacs-devel@gnu.org; Tue, 25 Apr 2006 18:57:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYWSu-0002Up-9D for emacs-devel@gnu.org; Tue, 25 Apr 2006 18:57:04 -0400 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FYWVQ-0004Gv-Iw; Tue, 25 Apr 2006 18:59:41 -0400 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id VAA00387; Tue, 25 Apr 2006 21:49:47 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:53433 Archived-At: Evening, Stefan! On Tue, 25 Apr 2006, Stefan Monnier wrote: >> OK. So FACENAME comes back as nil (which presumably means "don't apply a >> facename property") and the side effect is applying f-l-multiline if the >> buffer line matches the regexp. >Right. >>>> What about the run-time overhead of having an extra text property over >>>> the entire buffer? >>> It's not over the entire buffer. >> Load a buffer and wait for it to be jit-locked. The entire buffer will >> have been scanned and this text property, in effect, set to t or nil on >> every single byte. >Actually the `nil' value is not added, so the property is only added where >it's non-nil. Hence it's not added to the entire buffer. Maybe the 'nil' isn't explicitly added, but the entire font-lock region (or buffer) has to be scanned. Every time a region gets fontified, the f-l-m properties are erased and every multiline sequence in that region is recalculated. In the approach I favour, only the bits at the region boundaries need checking, and then only at the time they are needed. This continual erasure and recalculation of f-l-m properties could have a serious impact on the speed of C Mode, when that finally acquires a suitable region calcualtion function - because this function will essentially have to be c-beginning-of-statement-1, with various strategies, such as cacheing, to speed it up. Calculating this function for _every_ statement within the region would be prohibitively expensive. >>> And I haven't seen any evidence that it's noticeable (especially >>> compared the number of `face' properties or of the `fontified' >>> property added to the whole buffer). >> I'm sure it's not. >Good. >> Is it really that important to responsiveness whether the delay >> happens at the redisplay or immediately after the change? With the >> after-change f-l-e-r-f, only the two boundaries of the region get >> checked, plus any chunk boundaries when this is bigger than 500 bytes. >> With the extra pattern in f-l-keywords, then entire region gets >> checked. >But a single command may do thousands of buffer-modifications. What is a typical number for an "advanced" command? >Look at it this way. Let's define things as follows: >- a single buffer-modification, without your hook, takes time T1 >- font-locking, without my font-lock-multiline thingy, takes time T2 >- your hook takes times N1*T1 >- my font-lock-multiline takes time N2*T2 >So your approach can slow down user-visible execution by a fator N1, >whereas mine can slow it down by a factor N2. So the important question >(to me anyway) is whether N1 is expected to be bigger or smaller than >N2. Equally important is T1 and T2. >Note that in all likelyhood T2 is much larger than T1, so it should be >expected that N1 is significantly larger than N2. You've given a good argument for keeping both approaches available. >> expensive in aggregate - it marks _every_ sequence which must be >> atomically fontified, just in case that sequence might straddle a chunk >> boundary in the future. >No: it's only applied to those atomic elements which do straddle >a line boundary. My understanding of the form you were suggesting for AWK Mode's f-l-keywords, ("^.*\\\\\n" . (progn ......)), was that this regexp would be matched against ALL lines in the region, marking all multi-lines, in case they might in the future come to straddle chunk boundaries. >>> I'm as close as it gets to a font-lock maintainer. So from where I >>> stand, you're trying to impose your taste and judgment on me. >> I'm as close as it gets to a CC Mode maintainer at the moment. What's >> constraining my freedom in that department now? ;-) >We're talking about font-lock code here. You're free to do whatever you >like in cc-mode, including adding an advice to >font-lock-after-change-function. Richard has specifically required this advice to be eradicated, on the grounds that if such advice is necessary there's some deficiency in the underlying functionality, and that deficiency should be fixed. [ .... ] > Stefan -- Alan.