From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Aborting display. Is this possible? Date: Mon, 20 Oct 2014 11:09:49 +0000 Message-ID: <20141020110949.GA2947@acm.acm> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <20141019154255.GC3197@acm.acm> <83egu4c4om.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 1413803462 17273 80.91.229.3 (20 Oct 2014 11:11:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Oct 2014 11:11:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 20 13:10:55 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XgArT-0000Wm-CY for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 13:10:51 +0200 Original-Received: from localhost ([::1]:43967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgArS-0005DQ-Sm for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 07:10:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgArK-0005BI-Jk for emacs-devel@gnu.org; Mon, 20 Oct 2014 07:10:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgArB-0007Si-G3 for emacs-devel@gnu.org; Mon, 20 Oct 2014 07:10:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:27286 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgArA-0007SD-UQ for emacs-devel@gnu.org; Mon, 20 Oct 2014 07:10:33 -0400 Original-Received: (qmail 21991 invoked by uid 3782); 20 Oct 2014 11:10:31 -0000 Original-Received: from acm.muc.de (pD951B873.dip0.t-ipconnect.de [217.81.184.115]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 20 Oct 2014 13:10:30 +0200 Original-Received: (qmail 3154 invoked by uid 1000); 20 Oct 2014 11:09:49 -0000 Content-Disposition: inline In-Reply-To: <83egu4c4om.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175583 Archived-At: Hello, Eli. Before getting into your last post, I'll make explicit what I see, and what I'd like to see. On a large C Mode buffer (such as xdisp.c), hold down the PageDown key for, say, 10 seconds. What is seen: The screen freezes. After releasing the key, it takes many seconds (~10) before the current buffer position is displayed on the screen. What I'd like to see: The screen continuously updating with (not necessarily contiguous) parts of the buffer, the updating being frequent enough to give the illusion of continuous scrolling. On releasing the key, the screen "instantly" displaying the new buffer position. On Sun, Oct 19, 2014 at 09:09:13PM +0300, Eli Zaretskii wrote: > > Date: Sun, 19 Oct 2014 15:42:55 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > That's not what happens. What does happen is that redisplay _tries_ > > > several times to do its job, right after each PageDown keypress, each > > > time starting with the value of point it sees, then abandoning that > > > attempt because input arrives before it could finish. > > So if 35 PageDowns are received in a second, it starts redisplay after > > each and every one. > Yes, unless by the time Emacs finishes processing one PageDown key > there's another one in the keyboard queue. I'm not so sure of this. I think Emacs is completing the fontification for the screenful after each PageDown, only it is not physically displaying it. (See below). > > How much time does it take before checking for pending input? [ ... ] > It seems like you think Emacs is able to produce only a partial redraw > of the screen; if so, you are wrong: Emacs never does that. Redisplay > of each window (or maybe even each frame, I don't recall exactly) is > an atomic operation: it is either done completely, or not at all. > Emacs checks for pending input at strategic places, so that you never > see a partially incorrect display. OK. This sounds like a definite design decision. Thinking about it, it sounds very sensible. [ ... ] > Emacs first calculates the minimum portion of the screen that needs > redrawing (checking for input several times during this part, and > abandoning redisplay if there's input and redisplay-dont-pause is > nil). When these calculations are finished, it checks for input one > last time. If there's no input, or if redisplay-dont-pause is > non-nil, Emacs proceeds to actually drawing the parts that changed, > and redraws all that is needed without any further input checks. > Otherwise, the redisplay cycle is aborted. > This is done for every frame at least, perhaps even for each window (I > don't remember). I've written a little tool to scan a buffer for the `fontified' property. If I "reset" xdisp.c then hold down PageDown for ~10s, then I find that `fontified' has been set on _every_ buffer position from (point-min) to (point). This suggests a bug in either CC Mode or the command loop. emacs -Q. Load this file, get-fontified.el: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defvar regions nil) (defun get-fontified () "Display a list of regions which have the `fontified' property set. Retain this list in variable `regions'." (interactive) (setq regions nil) (let ((beg (if (get-text-property (point-min) 'fontified) (point-min) (next-single-property-change (point-min) 'fontified))) end) (while beg (setq end (or (text-property-any beg (point-max) 'fontified nil) (point-max))) (push (cons beg end) regions) (setq beg (next-single-property-change end 'fontified))) (setq regions (nreverse regions))) (message "Fontified regions: %s" regions)) (global-set-key [f10] 'get-fontified) (defun wipe-fontification () "Remove all fontification by switching to fundamental mode and back to C Mode." (interactive) (fundamental-mode) (c-mode)) (global-set-key [f11] 'wipe-fontification) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; At BOB xdisp.c, press F11, press and hold PageDown, release PageDown after ~10s, then press F10. This is what I see: Fontified regions: ((1 . 503768)) . Thus it seems either the command loop or CC Mode is fontifying _every_ position which PageDown is scanning over. -- Alan Mackenzie (Nuremberg, Germany).