From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#20180: Missing documentation about redisplay. Date: Mon, 23 Mar 2015 17:55:25 +0000 Message-ID: <20150323175524.GB23576@acm.fritz.box> References: <20150323160850.GA23576@acm.fritz.box> <83oanjr75n.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1427133390 24145 80.91.229.3 (23 Mar 2015 17:56:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Mar 2015 17:56:30 +0000 (UTC) Cc: 20180@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 23 18:56:20 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 1Ya6aC-0004wG-42 for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Mar 2015 18:56:12 +0100 Original-Received: from localhost ([::1]:57436 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya6aB-0007M5-JP for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Mar 2015 13:56:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya6a8-0007Hj-3e for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 13:56:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ya6a3-0004RS-2V for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 13:56:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya6a3-0004RK-00 for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 13:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ya6a2-0005pd-IP for bug-gnu-emacs@gnu.org; Mon, 23 Mar 2015 13:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Mar 2015 17:56: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.142713334722393 (code B ref 20180); Mon, 23 Mar 2015 17:56:02 +0000 Original-Received: (at 20180) by debbugs.gnu.org; 23 Mar 2015 17:55:47 +0000 Original-Received: from localhost ([127.0.0.1]:34099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ya6Zm-0005p6-RW for submit@debbugs.gnu.org; Mon, 23 Mar 2015 13:55:47 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:35843 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ya6Zk-0005ox-A9 for 20180@debbugs.gnu.org; Mon, 23 Mar 2015 13:55:45 -0400 Original-Received: (qmail 32823 invoked by uid 3782); 23 Mar 2015 17:55:41 -0000 Original-Received: from acm.muc.de (pD95199EB.dip0.t-ipconnect.de [217.81.153.235]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 23 Mar 2015 18:55:40 +0100 Original-Received: (qmail 23921 invoked by uid 1000); 23 Mar 2015 17:55:25 -0000 Content-Disposition: inline In-Reply-To: <83oanjr75n.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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:100850 Archived-At: Hi, Eli. On Mon, Mar 23, 2015 at 06:49:08PM +0200, Eli Zaretskii wrote: > > Date: Mon, 23 Mar 2015 16:08:50 +0000 > > From: Alan Mackenzie > > The elisp manual doesn't contain adequate documentation about > > (re)display. > > The topics not covered include > They include much more. Describing the display engine to any depth is > a research project, not a bug report. :-) > Maybe if you had more specific questions, they could be answered. What triggered my documentation search was looking at jit-lock-fontify-now. 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? Why does this trigger a redisplay when the setting of the properties during the previous redisplay cycle didn't? 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? If I were to execute the command `ignore' via a key sequence, would that trigger redisplay? If so, how much would get redrawn? > The closest thing to what you are asking for is in the large > commentary at the beginning of xdisp.c. > > 1. What triggers redisplay. > See below: this is already covered. > > 2. What portions of the frame/all frames get redisplayed when a > > redisplay occurs, and how does this relate to the answer to 1.. > > There is a partial answer to 1. on the page "Forcing Redisplay" which > > states that "Emacs normally tries to redisplay the screen whenever it > > waits for input.", but this is clearly incomplete - redisplay also > > happens in the absence of input (e.g. by context fontification). > I don't understand what you are saying here: "waiting for input" and > "there's no input" is not a contradiction, on the contrary: you wait > for input when there's none. And what is "context fontification"? 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"? Or does the expiry of the timer count as "input" here? Or is something other than input (?a buffer change) triggering this second redisplay? > > 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. -- Alan Mackenzie (Nuremberg, Germany).