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: Fri, 29 Jan 2010 11:09:47 +0200 Message-ID: <83zl3xs2ec.fsf@gnu.org> References: <20100127135716.GA3432@muc.de> <20100127153733.GD3432@muc.de> <83k4v34f49.fsf@gnu.org> <83fx5r48gd.fsf@gnu.org> <83bpget0gv.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1264756656 26914 80.91.229.12 (29 Jan 2010 09:17:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2010 09:17:36 +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 Fri Jan 29 10:17:33 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 1Namyq-0006Ja-EP for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 10:17:32 +0100 Original-Received: from localhost ([127.0.0.1]:54298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Namyp-0006vn-Ml for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 04:17:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NamsO-0007Yv-0K for emacs-devel@gnu.org; Fri, 29 Jan 2010 04:10:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NamsI-0007Pi-Ox for emacs-devel@gnu.org; Fri, 29 Jan 2010 04:10:50 -0500 Original-Received: from [199.232.76.173] (port=59693 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NamsI-0007PL-8j for emacs-devel@gnu.org; Fri, 29 Jan 2010 04:10:46 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:35665) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NamsH-0007Zf-Oj for emacs-devel@gnu.org; Fri, 29 Jan 2010 04:10:46 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KX0005003C3N400@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 29 Jan 2010 11:09:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.180.161]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KX00021G44A7IE0@a-mtaout20.012.net.il>; Fri, 29 Jan 2010 11:09:47 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:120630 Archived-At: > From: Stefan Monnier > Cc: acm@muc.de, emacs-devel@gnu.org > Date: Thu, 28 Jan 2010 18:12:11 -0500 > > >> > 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? > > It could simply record that position in some variable. > > If the buffer is shown in two windows, that "last position" might be > megabytes away. It doesn't matter, because the redisplay works on windows one by one, and the iterator structure is initialized anew for each one of them. > >> > 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. > >> 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. > > > That would just mean that the 1KB function gets called, detects that > > it has nothing to do, and returns. (Assuming it records its last > > chunk in some variable.) > > 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. > 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? > > 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. > 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. I'd say calling the hook when redisplay is done is more useful. But I didn't analyze the possible uses of that, so I may be mistaken. > admittedly, which would be an alternative to post-command-hook Redisplay is not always triggered by commands. Input from a process is a notable example when it isn't. Mouse movement is another. Window size changes are yet another. > several post-command-hooks would actually also like to be run at > times where no command was performed (e.g. timer event, filter, > sit-for, ...). Exactly.