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: Fri, 29 Jan 2010 13:08:22 -0500 Message-ID: References: <20100127135716.GA3432@muc.de> <20100127153733.GD3432@muc.de> <83k4v34f49.fsf@gnu.org> <83fx5r48gd.fsf@gnu.org> <83bpget0gv.fsf@gnu.org> <83zl3xs2ec.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 1264788528 26830 80.91.229.12 (29 Jan 2010 18:08:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2010 18:08:48 +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 Fri Jan 29 19:08:43 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 1NavGq-0002pc-1B for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 19:08:40 +0100 Original-Received: from localhost ([127.0.0.1]:45088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NavGp-0004kS-5x for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 13:08:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NavGh-0004ia-K4 for emacs-devel@gnu.org; Fri, 29 Jan 2010 13:08:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NavGc-0004ed-Td for emacs-devel@gnu.org; Fri, 29 Jan 2010 13:08:31 -0500 Original-Received: from [199.232.76.173] (port=35319 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NavGc-0004eS-Oz for emacs-devel@gnu.org; Fri, 29 Jan 2010 13:08:26 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:58053) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NavGa-0006Dx-25; Fri, 29 Jan 2010 13:08:24 -0500 Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o0TI8M7r009221; Fri, 29 Jan 2010 13:08:22 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 654D93A7A3; Fri, 29 Jan 2010 13:08:22 -0500 (EST) In-Reply-To: <83zl3xs2ec.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Jan 2010 11:09:47 +0200") 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 RV3459=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:120661 Archived-At: >> >> > 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). >> > The effect is the same. >> Not quite: there are other users of jit-lock than font-lock (mostly >> glasses-mode, but Alan might become the third user, linum could be >> another user, ...). > My point was that the Lisp function which is invoked via this > mechanism can do its work in any position it finds fit, not > necessarily the position passed to it by the display engine. Right, but for efficiency reason, we'd like to make sure it does its job at a place that's useful. With a single fontification-function, the `fontified' text property provides this information very precisely. >> This assumption is currently not true. Recording which part is already >> handled and which part is not yet handled is usually done either by the >> `fontified' property (if you use fontification-functions) or somehow by >> `jit-lock'. > That ``somehow'' is what I meant when I mentioned that the function > could record where it left off in some variable. jit-lock uses the `fontified' text property for that, and then forces all its clients to fontify (at least) the same part of the buffer, which is what fontification-functions can't do because it only provides the `start' but not the `end' argument. >> If such a problem of efficiency needs to be solved, we could indeed >> probably hack it up via some such variable, tho it would be mighty ugly, >> since the function wouldn't necessarily know what happened between the >> last time it was called and the current time, so it would need to >> somehow figure out whether "nothing happened and I can just return" or >> whether in the contrary the buffer has been modified and the >> fontification that was computed last time needs to be refreshed. > Anything that's needed for such a decision except the position and the > buffer or window id? MODIFF, probably. >> > Fine with me. But I do think we may wish to have some more general >> > redisplay-hook feature, that isn't tailored to fontification. >> Not sure what you're thinking of. > I was thinking about a hook that does not depend on the `fontified' > property. What would it depend on and what info would it provide to its functions? >> I'd be interested in a before-redisplay-hook > Why ``before''? There isn't much a Lisp code can do to affect > redisplay, if it is called _by_ redisplay. Just like fontification-functions, it can affect the faces, the color, ... everything. See my examples of reveal-mode and cursor color. > I'd say calling the hook when redisplay is done is more useful. That's an alternative, indeed, tho I'm not sure what it could be used for (I do see that it could receive extra info such as which part of which buffer needed redisply and things like that, but again, no use-case springs to mind). Stefan