From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is there something like `on-display-functions'? Date: Thu, 28 Jan 2010 01:49:21 -0500 Message-ID: References: <20100127135716.GA3432@muc.de> <20100127153733.GD3432@muc.de> <83k4v34f49.fsf@gnu.org> <83fx5r48gd.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1264661385 2539 80.91.229.12 (28 Jan 2010 06:49:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jan 2010 06:49:45 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 28 07:49:39 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 1NaOC9-0001PZ-1s for ged-emacs-devel@m.gmane.org; Thu, 28 Jan 2010 07:49:37 +0100 Original-Received: from localhost ([127.0.0.1]:45738 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaOC8-0003mS-Av for ged-emacs-devel@m.gmane.org; Thu, 28 Jan 2010 01:49:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NaOBz-0003la-6O for emacs-devel@gnu.org; Thu, 28 Jan 2010 01:49:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NaOBv-0003jq-2U for emacs-devel@gnu.org; Thu, 28 Jan 2010 01:49:26 -0500 Original-Received: from [199.232.76.173] (port=45839 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaOBu-0003jg-Kk for emacs-devel@gnu.org; Thu, 28 Jan 2010 01:49:22 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:34038) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NaOBu-0001Gg-9l for emacs-devel@gnu.org; Thu, 28 Jan 2010 01:49:22 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1NaOBt-0007U9-Tj; Thu, 28 Jan 2010 01:49:21 -0500 In-reply-to: (message from Stefan Monnier on Wed, 27 Jan 2010 16:04:07 -0500) 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:120549 Archived-At: > From: Stefan Monnier > Cc: acm@muc.de, emacs-devel@gnu.org > Date: Wed, 27 Jan 2010 16:04:07 -0500 > > 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. It's just the place where redisplay will stop next and call those functions again. 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. 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. 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?