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: Sun, 19 Oct 2014 15:42:55 +0000 Message-ID: <20141019154255.GC3197@acm.acm> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.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 1413733739 29420 80.91.229.3 (19 Oct 2014 15:48:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 15:48:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 19 17:48:52 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 1Xfsiy-0002ea-JN for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 17:48:52 +0200 Original-Received: from localhost ([::1]:40425 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xfsiy-0001Lx-7a for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 11:48:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xfsiq-0001Lo-3j for emacs-devel@gnu.org; Sun, 19 Oct 2014 11:48:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xfsii-0006K0-N0 for emacs-devel@gnu.org; Sun, 19 Oct 2014 11:48:43 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:16522 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xfsii-0006Jm-Cv for emacs-devel@gnu.org; Sun, 19 Oct 2014 11:48:36 -0400 Original-Received: (qmail 30365 invoked by uid 3782); 19 Oct 2014 15:48:34 -0000 Original-Received: from acm.muc.de (pD95196BD.dip0.t-ipconnect.de [217.81.150.189]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Oct 2014 17:48:33 +0200 Original-Received: (qmail 4271 invoked by uid 1000); 19 Oct 2014 15:42:55 -0000 Content-Disposition: inline In-Reply-To: <83lhoccdv7.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:175564 Archived-At: Hi, Eli. On Sun, Oct 19, 2014 at 05:50:52PM +0300, Eli Zaretskii wrote: > > 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. Ah. OK. > > 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. I asked for it, it seems I've got it already. > > 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. So if 35 PageDowns are received in a second, it starts redisplay after each and every one. How much time does it take before checking for pending input? Could my problem be that this time is short enough that that no intermediate screen has time to display a fragment, but long enough that there's a significant pause when the user finally takes her finger of PageDown? What is stopping a fragment of each intermediate screen (or of some of them) being displayed? Could it be that the display engine calculates an entire screenful of glyphs before it starts displaying them on the physical screen? > 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. -- Alan Mackenzie (Nuremberg, Germany).