From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20180: Missing documentation about redisplay. Date: Mon, 23 Mar 2015 22:52:00 +0200 Message-ID: <83bnjjqvwv.fsf@gnu.org> References: <20150323160850.GA23576@acm.fritz.box> <83oanjr75n.fsf@gnu.org> <20150323175524.GB23576@acm.fritz.box> <83lhinr2j4.fsf@gnu.org> <20150323201752.GC23576@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427144014 14940 80.91.229.3 (23 Mar 2015 20:53:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Mar 2015 20:53:34 +0000 (UTC) Cc: 20180@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 23 21:53:22 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ya9LZ-0006vi-4e for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Mar 2015 21:53:17 +0100 Original-Received: from localhost ([::1]:58001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya9LY-000858-FL for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Mar 2015 16:53:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya9LQ-000846-Dx for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 16:53:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ya9LK-0001Q7-Kx for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 16:53:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya9LK-0001Q3-HU for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 16:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ya9LK-0001e6-8d for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 16:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Mar 2015 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20180-submit@debbugs.gnu.org id=B20180.14271439456276 (code B ref 20180); Mon, 23 Mar 2015 20:53:02 +0000 Original-Received: (at 20180) by debbugs.gnu.org; 23 Mar 2015 20:52:25 +0000 Original-Received: from localhost ([127.0.0.1]:34208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ya9Ki-0001d8-A3 for submit@debbugs.gnu.org; Mon, 23 Mar 2015 16:52:24 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:62703) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ya9Ke-0001cq-LP for 20180@debbugs.gnu.org; Mon, 23 Mar 2015 16:52:22 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NLO00600N31XN00@a-mtaout20.012.net.il> for 20180@debbugs.gnu.org; Mon, 23 Mar 2015 22:52:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLO00600NB1LTB0@a-mtaout20.012.net.il>; Mon, 23 Mar 2015 22:52:13 +0200 (IST) In-reply-to: <20150323201752.GC23576@acm.fritz.box> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100865 Archived-At: > Date: Mon, 23 Mar 2015 20:17:52 +0000 > Cc: 20180@debbugs.gnu.org > From: Alan Mackenzie > > > > There, if jit-lock suspects that properties at an > > > earlier location in the buffer have been changed, it arranges that after > > > the end of the current display cycle, some text properties at some of > > > these locations get set, thus triggering another redisplay. > > > > How? > > > By changing the special text property 'fontified'. > > > > Why does this trigger a redisplay when the setting of the > > > properties during the previous redisplay cycle didn't? > > > I don't understand the question. What "setting of properties" during > > which "previous redisplay cycle" do you have in mind? > > 1. Redisplay cycle 1 starts. > 2. First 500-byte chunk gets fontified through fontification-functions. > 3. Second 500-byte chunk fontification starts. > 4. jit-lock-fontify-now applies face properties to a few characters of > the first 500-byte chunk at locations 496, 497, 498, 499. > 5. jit-lock-fontify-now arranges for 10. to happen at the expiry of a 0 > second timeout. (`run-with-timer') > 6. Second 500-byte chunk is completely fontified. It gets drawn on the > screen. > 7. Redisplay cycle 1 is now complete. > > 10. (At expiry of 0 second timeout), jit-lock-force-redisplay applies > text property (fontified t) to location 496, 497, 498, 499. 496..499 > already had the property (fontified t). > 11. Redisplay cycle 2 starts, having been triggered by 10. > 12. ???? Redisplay draws 496, .., 499 on the screen, but no others. > 13. Redisplay cycle 2 is now complete. > > I think I meant to ask: why does setting text property 'fontified to t at > stage 10 trigger redisplay cycle 2, whereas setting them at stage 4.5 > wouldn't have done? Because stage 10 happens _after_ redisplay cycle 1 is complete. Changing text properties after redisplay triggers another redisplay of the buffer portion where the properties changed, because changes in properties bump up the buffer-changed counter, and redisplay examines that counter to determine whether anything changed since the previous redisplay cycle. IOW, if those properties weren't changed after redisplay finished, the next redisplay would have decided that no changes happened, and do nothing. > In 10. above, the `fontified' text property is set to the value it > already had. This seems to be sufficient to trigger a redisplay. Because it counts as a change regardless.