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: Sun, 19 Oct 2014 17:50:52 +0300 Message-ID: <83lhoccdv7.fsf@gnu.org> References: <20141019141712.GB3197@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413730296 24603 80.91.229.3 (19 Oct 2014 14:51:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 14:51:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 19 16:51:29 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 1XfrpQ-0003pg-0W for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 16:51:28 +0200 Original-Received: from localhost ([::1]:40280 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfrpP-0002hC-KG for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 10:51:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xfrp8-0002h5-JA for emacs-devel@gnu.org; Sun, 19 Oct 2014 10:51:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xfrp3-0006oP-VC for emacs-devel@gnu.org; Sun, 19 Oct 2014 10:51:10 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:50947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xfrp3-0006oD-N4 for emacs-devel@gnu.org; Sun, 19 Oct 2014 10:51:05 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NDP00F004YX4500@mtaout29.012.net.il> for emacs-devel@gnu.org; Sun, 19 Oct 2014 17:49:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDP00F5U57A1Z10@mtaout29.012.net.il>; Sun, 19 Oct 2014 17:49:58 +0300 (IDT) In-reply-to: <20141019141712.GB3197@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.185 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:175562 Archived-At: > Date: Sun, 19 Oct 2014 14:17:13 +0000 > From: Alan Mackenzie > > A lisp program can influence an ongoing display operation by setting > redisplay-dont-pause to nil. When input arrives, the displaying is > immediately paused. It is not paused, it is aborted. Emacs cannot "pause" redisplay and then "resume" it. > However, at the next opportunity, the displaying carries on where it > left off, rather than being aborted. I don't understand what you mean by "carries on where it left off". Emacs doesn't record where redisplay "left off", and cannot resume an interrupted redisplay cycle. It simply starts redisplay anew on the next opportunity. > Why? Better to handle a user auto-repeating on the PageDown key. On my > system, auto-repeat is around 35-40 characters per second, on a window > with 65 lines. In my favourite mode, display can not keep up. If I set > redisplay-dont-pause to nil and hold down PageDown, what the user sees > is frozen for several seconds whilst display determines the display of > every intermediate buffer position (which isn't going to get displayed > anyway) before finally reaching point. 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. Emacs never examines portions of the buffer that don't need to be on the screen (or a few lines of text above or below that). It always starts with the current value of point, and works from that. So intermediate buffer positions will never be examined. > Would it be possible to enhance display such that incoming input would > abort the current display operation? It does already. Emacs simply doesn't know any better.