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 20:10:07 +0300 Message-ID: <83r3y2brbk.fsf@gnu.org> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <20141019154255.GC3197@acm.acm> <83egu4c4om.fsf@gnu.org> <20141020110949.GA2947@acm.acm> <8338aidbcq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413825062 4592 80.91.229.3 (20 Oct 2014 17:11:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Oct 2014 17:11:02 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 20 19: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 1XgGTs-0007j5-LJ for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 19:10:52 +0200 Original-Received: from localhost ([::1]:46037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgGTs-0001Sb-38 for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 13:10:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgGTQ-0001SU-Ov for emacs-devel@gnu.org; Mon, 20 Oct 2014 13:10:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgGTL-0004rQ-4D for emacs-devel@gnu.org; Mon, 20 Oct 2014 13:10:24 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:56840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgGTK-0004rA-S6 for emacs-devel@gnu.org; Mon, 20 Oct 2014 13:10:19 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NDR00H0064FYO00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 20 Oct 2014 20:10:16 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDR00HL26D3H480@a-mtaout22.012.net.il>; Mon, 20 Oct 2014 20:10:16 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:175599 Archived-At: > From: Stefan Monnier > Cc: Alan Mackenzie , emacs-devel@gnu.org > Date: Mon, 20 Oct 2014 12:56:56 -0400 > > > 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. > > This is the case when processing the scroll-up-command takes less time > than the repeat rate. That's what I said, yes. > > Now, what happens when you release the key? The input queue is still > > full of unprocessed PageDown keys. > > If processing a single scroll-up-command takes less time than the repeat > rate, the input queue should never have many unprocessed PageDown events > (that's the whole reason why we check the input queue before entering > redisplay). > > So I still don't understand why we see this long delay when releasing > the key. Not every screenful needs the same time to redisplay. There comes a screen that needs more, and the queue is no longer empty.