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: Is there something like `on-display-functions'? Date: Thu, 28 Jan 2010 14:37:11 -0500 Message-ID: References: <20100127135716.GA3432@muc.de> <20100127153733.GD3432@muc.de> <83k4v34f49.fsf@gnu.org> <83fx5r48gd.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264707684 19764 80.91.229.12 (28 Jan 2010 19:41:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jan 2010 19:41:24 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 28 20:41:21 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NaaEz-0000Wo-63 for ged-emacs-devel@m.gmane.org; Thu, 28 Jan 2010 20:41:21 +0100 Original-Received: from localhost ([127.0.0.1]:50855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaaEy-0004J6-Mr for ged-emacs-devel@m.gmane.org; Thu, 28 Jan 2010 14:41:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NaaB7-00083y-Aj for emacs-devel@gnu.org; Thu, 28 Jan 2010 14:37:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NaaB2-0007xf-LS for emacs-devel@gnu.org; Thu, 28 Jan 2010 14:37:20 -0500 Original-Received: from [199.232.76.173] (port=51416 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaaB2-0007xJ-9D for emacs-devel@gnu.org; Thu, 28 Jan 2010 14:37:16 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:39996) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NaaAz-000382-Ij; Thu, 28 Jan 2010 14:37:13 -0500 Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o0SJbBFG005836; Thu, 28 Jan 2010 14:37:11 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 913873A7A3; Thu, 28 Jan 2010 14:37:11 -0500 (EST) In-Reply-To: (Eli Zaretskii's message of "Thu, 28 Jan 2010 01:49:21 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3458=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:120606 Archived-At: >> Unless the two functions cooperate, there's no reason to presume that >> the two functions will fontify the same amount of text, since the amount >> is mostly arbitrarily chosen by the function themselves (and may need >> rounding up because of line-granularity or other >> foo-region-extend-function). >> >> So if each function is written independently, it will (in general) not >> fontify the same amount of text as the others, and it won't know how >> much the others (if any) have fontified. So none of the functions will >> actually know on which portion of the text the `fontified' property >> should be applied. > The place where `fontified' property with a nil value is left after > all fontification-functions are run is not very important. On the contrary, it's very important. > It's just the place where redisplay will stop next and call those > functions again. If function foo1 fontified to location 123 and foo2 to location 245 and the property is set until 245 and the window ends at 200, then foo1 will not be called again, and the display will show 123-200 without foo1's fontification. > If a function on that list needs to be sure it does > not miss any text due to the position where a nil-valued `fontified' > is placed, it should simply start from some earlier position, not from > the one with which it is invoked. Then it could search for the first > position where it needs to do its job, and resume there. Which "earlier position"? How does the function know how far back it would need to look? > Note that the JIT Lock function that gets invoked via > fontification-functions always starts from the beginning of the line > to which the position it was invoked with belongs. So it is already > doing something similar, albeit for different reasons. That used to be the case, but now this region-extension has been moved to font-lock (where it belongs). > OTOH, it would be a simple change to have the loop in > handle_fontified_prop maintain the lowest buffer position of those > where the `fontified' property was placed by any of the functions it > invokes, and reset the value of that property to nil for that position > after the loop finishes. Would that resolve the difficulty? We could try and solve the problem this way, yes. Then again, it could result in serious inefficiency if one of the functions works on 100B chunks and the other on 1KB chunks, forcing the 1KB chunks to be recomputed redundantly 10 times. This said, I don't think it's a serious problem. The way I look at it, we should have used fontification-function rather than fontification-functions, and that's it. The "multiplexing" of several functions on this hook can be (and is) performed by jit-lock, where it's easier to be more clever (although currently jit-lock is not terribly clever either). Stefan