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: Aborting display. Is this possible? Date: Mon, 20 Oct 2014 18:12:05 +0300 Message-ID: <8338aidbcq.fsf@gnu.org> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <20141019154255.GC3197@acm.acm> <83egu4c4om.fsf@gnu.org> <20141020110949.GA2947@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413817961 8216 80.91.229.3 (20 Oct 2014 15:12:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Oct 2014 15:12:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 20 17:12:34 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 1XgEdK-0003mh-Dv for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 17:12:30 +0200 Original-Received: from localhost ([::1]:45417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgEdJ-00047t-TZ for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 11:12:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgEdB-00046Q-4n for emacs-devel@gnu.org; Mon, 20 Oct 2014 11:12:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgEd6-0001if-2V for emacs-devel@gnu.org; Mon, 20 Oct 2014 11:12:21 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:39878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgEd5-0001hY-Lf for emacs-devel@gnu.org; Mon, 20 Oct 2014 11:12:15 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NDR00O000EA4300@mtaout25.012.net.il> for emacs-devel@gnu.org; Mon, 20 Oct 2014 18:07:34 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDR00NQD0OMPQ10@mtaout25.012.net.il>; Mon, 20 Oct 2014 18:07:34 +0300 (IDT) In-reply-to: <20141020110949.GA2947@acm.acm> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:175590 Archived-At: > Date: Mon, 20 Oct 2014 11:09:49 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > 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. I understand the desire, and I'm not saying it isn't reasonable. So please don't take what's below as a rebuttal; I'm just trying to explain how the current Emacs design works against your wishes, and what could/should be changed for your wishes to maybe become reality. I will probably say some (or many) things that you already know, so please bear with me. First, Emacs's basic design is that it processes all the available input before it enters redisplay. As long as there's input in the input queue, Emacs will not call redisplay. (There are 2 exceptions to this rule: processing input could indirectly call the 'redisplay' function; and messages in the echo area produced while processing input require a kind of "partial" redisplay to show the echo area.) Why? because processing input allows to avoid showing the user a screen that is outdated from the user's POV, given that input more often than not changes what should be displayed. Another part of this puzzle is that redisplay includes fontification of the visible portion of the buffer. Emacs applies the font-lock faces (and any other faces) during the 1st stage of its redisplay cycle, when it computes the so-called "glyph matrices", which are data structures maintained for each window that describe what the updated screen should look like. As David points out, it is impossible to compute the glyph matrices without applying the faces, because faces change the metrics of each character, and thus affect the layout, which is what glyph matrices are all about. The final part of the puzzle is what the scroll-up-command does when Emacs processes a single PageDown keypress. It computes the new starting point for the window, which (if we neglect complications) is simply the beginning of line N screen lines below the original window start, where N is almost the height of the window. (Note that I wrote "screen lines", not "physical lines", so this is not entirely trivial when there are continuation lines and variable-size fonts.) Then it determines whether this change of the window-start requires to move point to bring it into the view, and if so, moves point as well. So, after processing a single PageDown key, the window has a new starting point, and point in that window's buffer has been moved. If, after processing this single PageDown key, the input queue is empty (as it is when you lean on the key, because Emacs finishes the above processing in less time than the auto-repeat interval), Emacs enters redisplay. Redisplay computes the glyph matrix of the window given its start point as set by scroll-up-command; as part of this matrix computation, the display engine applies all the font-lock properties to the text, and sets the 'fontified' property on that text. Then, just before it is about to redraw the window given the new glyph matrix, it checks for input. If there's input available, and redisplay-dont-pause is nil, the window will not be redrawn, i.e. this redisplay cycle will be aborted. Then the same will happen again for the next PageDown key. The result is a frozen window display, because all the attempts to redisplay are aborted due to input rate that is high enough to preempt redisplay, but not high enough to prevent Emacs from entering redisplay after every (or almost every) PageDown key. To see more frequent updates that give an illusion of scrolling, we would need a feature that ignores the input availability, or maybe dynamically changes the number of input events that could be ignored when redisplay falls behind. We don't have such a feature. Now, what happens when you release the key? The input queue is still full of unprocessed PageDown keys. As I explained above, Emacs will drain the entire input queue before it enters redisplay; thus the long delay you see after releasing the key. You want Emacs to "immediately" display the new buffer position, but this is impossible without some code that would quickly scan the input queue, analyze what's there, and "understand" that 100 PageDown keystrokes can be "optimized" by executing a single scroll-up-command with a suitable argument. IOW, we would need some input preprocessing stage that could "optimize" input by replacing a series of commands with a single command, and do that cheaply. We don't have such a feature; patches to add it will probably be welcome.