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 22:53:52 +0200 Message-ID: <83bpget0gv.fsf@gnu.org> 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 1264712054 3922 80.91.229.12 (28 Jan 2010 20:54:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jan 2010 20:54:14 +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 21:54:08 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 1NabNP-0005Z8-CF for ged-emacs-devel@m.gmane.org; Thu, 28 Jan 2010 21:54:07 +0100 Original-Received: from localhost ([127.0.0.1]:44298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NabNO-0003WS-S6 for ged-emacs-devel@m.gmane.org; Thu, 28 Jan 2010 15:54:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NabNI-0003TD-44 for emacs-devel@gnu.org; Thu, 28 Jan 2010 15:54:00 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NabND-0003OB-Ma for emacs-devel@gnu.org; Thu, 28 Jan 2010 15:53:59 -0500 Original-Received: from [199.232.76.173] (port=54116 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NabND-0003O5-GZ for emacs-devel@gnu.org; Thu, 28 Jan 2010 15:53:55 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:52612) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NabND-0004n9-2X for emacs-devel@gnu.org; Thu, 28 Jan 2010 15:53:55 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KWZ0020061MGI00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 28 Jan 2010 22:53:53 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.180.161]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KWZ002CW61SEZ00@a-mtaout20.012.net.il>; Thu, 28 Jan 2010 22:53:53 +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:120615 Archived-At: > From: Stefan Monnier > Cc: acm@muc.de, emacs-devel@gnu.org > Date: Thu, 28 Jan 2010 14:37: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. > > 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. > > 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. 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.) Anyway, in my testing, this inefficiency is not serious. The bidi redisplay sometimes needs to traverse the same ``stop point'' (stop_charpos in the iterator structure) several times, first from left to right, then right to left, etc., because it must do that in the visual order, and still the display is fast enough to not annoy or even show a noticeable delay (at least on a machine such as fencepost)[1]. > 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). Fine with me. But I do think we may wish to have some more general redisplay-hook feature, that isn't tailored to fontification. ---------------------- [1] As usual, our mostly wrong impression about the speed of our our machines stems from the fact that most of the time we see them being busy moving pixels from here to there. When time comes to exercise raw computing power, modern machines are lightning fast. A case in point is the bidi reordering code. Its processing core is no less than 1500 lines of C, which replace these two lines in the current unidirectional display engine: IT_BYTEPOS (*it) += it->len; IT_CHARPOS (*it) += 1; (For those who are not familiar with the display engine, this advances the iterator by one character and the corresponding number of bytes, as determined by the length of its multibyte sequence.) IOW, instead of two increments, we run a 1500-line monster. Mind you, this runs in the innermost loop of the display engine! Would you be surprised to know that I got scared when I finished implementing the reordering code? I was afraid that the resulting redisplay will crawl. So I timed the code, by writing a trivial wc workalike, and timing it against the real wc. To my surprise it worked at half the speed of wc, which is pretty darn fast, concerning what it needs to do instead of just incrementing a pointer. Morale: never underestimate what a modern CPU can do when it does not need to move pixels ;-)