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 20:29:03 +0200 Message-ID: <83lhinr2j4.fsf@gnu.org> References: <20150323160850.GA23576@acm.fritz.box> <83oanjr75n.fsf@gnu.org> <20150323175524.GB23576@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427135424 27083 80.91.229.3 (23 Mar 2015 18:30:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Mar 2015 18:30:24 +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 19:30:15 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 1Ya777-0005EZ-6p for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Mar 2015 19:30:13 +0100 Original-Received: from localhost ([::1]:57534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya776-0001kA-CT for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Mar 2015 14:30:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya771-0001ii-WF for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 14:30:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ya76y-0006g0-Pc for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 14:30:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya76y-0006eS-N5 for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 14:30:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ya76x-0006dG-QS for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 14:30:03 -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 18:30:03 +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.142713536725430 (code B ref 20180); Mon, 23 Mar 2015 18:30:03 +0000 Original-Received: (at 20180) by debbugs.gnu.org; 23 Mar 2015 18:29:27 +0000 Original-Received: from localhost ([127.0.0.1]:34109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ya76N-0006c4-1h for submit@debbugs.gnu.org; Mon, 23 Mar 2015 14:29:27 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:35784) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ya76J-0006bj-NG for 20180@debbugs.gnu.org; Mon, 23 Mar 2015 14:29:25 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NLO00J00GLAHH00@a-mtaout23.012.net.il> for 20180@debbugs.gnu.org; Mon, 23 Mar 2015 20:29:17 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLO00J06GOSH410@a-mtaout23.012.net.il>; Mon, 23 Mar 2015 20:29:16 +0200 (IST) In-reply-to: <20150323175524.GB23576@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:100851 Archived-At: > Date: Mon, 23 Mar 2015 17:55:25 +0000 > Cc: 20180@debbugs.gnu.org > From: Alan Mackenzie > > What triggered my documentation search was looking at > jit-lock-fontify-now. Note that digging into JIT Lock means going deep into the internals of the display engine. It's no accident that jit-lock.el was written by Gerd Moellmann, who designed and implemented the current display engine. IOW, it's by no means ELisp manual level stuff (although I of course agree that IWBN to have the display engine's internals described in full, along with all the other internals). > 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? > In the new redisplay, does the whole frame/window/minibuffer get > redrawn (for whatever value of "redraw") or just the bits where text > properties were set? This depends on what you mean by "redraw". A redisplay cycle has 2 phases. In the first phase, Emacs examines the visible portion of the buffer and tries to determine the minimal number of screen lines that might need to be redrawn; it then prepares the corresponding portions of the glyph matrix for those screen lines. Normally, only the screen lines where the 'fontified' text property changed will be considered. In the second phase of redisplay, the prepared glyph matrix is compared to the previous one, which describes what's on the glass, and only the different portions are actually redrawn. It could be that nothing needs to be redrawn at all. > If I were to execute the command `ignore' via a key sequence, would that > trigger redisplay? Yes, redisplay is triggered each time Emacs waits for more input and has nothing else to do. > If so, how much would get redrawn? Nothing at all, since nothing changed. > I read the "whenever" as meaning "when it's waiting for input, it tries > _once_ to redisplay". Having tried once, and 0.5s > (jit-lock-context-time) have passed, then jit-lock-context-fontify kicks > in to fontify screen lines below where a buffer change happened. Another > redisplay then happens. What triggers this second redisplay, given there > hasn't been any more "input"? The JIT Lock timer. > Or does the expiry of the timer count as "input" here? Or is > something other than input (?a buffer change) triggering this second > redisplay? Yes, timers have the same effect as input: they return to the command loop after the timer function is run, and the command loop enters redisplay if there's no input. > > > One clearly needs an answer to 2. if one ever wants to cause the > > > redisplay of a particular part of a window or frame. > > > To do that, you need to change the text of that part or the text > > properties/overlays that affect how that part looks on display. But > > you most probably already know that, so I'm again not sure what the > > question is. > > In jit-lock-fontify-now, the top half of a screen window has just been > redisplayed, and j-l-fontify-now is busily applying faces for the next > 500-byte chunk. In so doing, it sets faces in the part of the window > that have already been redisplayed. This is apparently insufficient in > itself to trigger another redisplay of those already displayed window > parts. I would like to understand why. jit-lock-fontify-now can be called in 2 different ways. One is as part of redisplay itself, because jit-lock-function, which calls jit-lock-fontify-now, is added to fontification-functions, which are run by the display engine when it bumps into a buffer position that has the 'fontified' text property whose value is nil. When jit-lock-fontify-now is called by this mechanism, it fontifies portions that were not yet displayed. After fontification-functions return, the display engine re-examines the buffer position where they were called, since it knows that faces could change there. This constitutes "another redisplay" you were looking for, without actually triggering a full redisplay cycle. Keep in mind that the display engine examines buffer text one character at a time, so it is only ever interested in the faces at the single buffer position it is examining. The other way jit-lock-fontify-now is called is from the Jit Stealth or deferred Jit Lock, in which case it does trigger another redisplay, as you expect. HTH