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:40:07 +0300 Message-ID: <83oat6bpxk.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> <83r3y2brbk.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413826863 27786 80.91.229.3 (20 Oct 2014 17:41:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Oct 2014 17:41:03 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 20 19:40: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 1XgGww-0007Hc-Qm for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 19:40:54 +0200 Original-Received: from localhost ([::1]:46139 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgGww-0007m6-B6 for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 13:40:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgGwY-0007l7-8x for emacs-devel@gnu.org; Mon, 20 Oct 2014 13:40:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgGwS-0006Kh-LE for emacs-devel@gnu.org; Mon, 20 Oct 2014 13:40:29 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:57325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgGwS-0006Jq-DU for emacs-devel@gnu.org; Mon, 20 Oct 2014 13:40:24 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDR00C007QYDE00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 20 Oct 2014 20:40:16 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDR00B9A7R4SV80@a-mtaout20.012.net.il>; Mon, 20 Oct 2014 20:40:16 +0300 (IDT) In-reply-to: <83r3y2brbk.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:175602 Archived-At: > Date: Mon, 20 Oct 2014 20:10:07 +0300 > From: Eli Zaretskii > Cc: acm@muc.de, emacs-devel@gnu.org > > > > 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. In addition, there are 2 places where auto-repeated keystrokes wait: one is the Emacs keyboard buffer, the other is the system input queue, since when we process keys we don't call the read_socket_hook. If you put a breakpoint in kbd_buffer_store_event and kbd_buffer_get_event, and define breakpoint commands that display the queue size, you will see that when you release the key, the queue size decreases to zero, then jumps to a large number, then decreases again, and finally the window is redisplayed. To me this means we have a lot of unprocessed keys in both queues. IOW, when the queue fills up because some screen took too long to display, Emacs doesn't succeed in emptying it, as long as the key is pressed.