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: redisplay-dont-pause Date: Fri, 16 Sep 2011 10:23:51 +0300 Message-ID: <83obyluf08.fsf@gnu.org> References: <83ipovw2z2.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1316157842 4448 80.91.229.12 (16 Sep 2011 07:24:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Sep 2011 07:24:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 16 09:23:58 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R4SmC-00024Y-Qm for ged-emacs-devel@m.gmane.org; Fri, 16 Sep 2011 09:23:57 +0200 Original-Received: from localhost ([::1]:59491 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4SmB-0006NE-Dg for ged-emacs-devel@m.gmane.org; Fri, 16 Sep 2011 03:23:55 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Sm8-0006Mw-By for emacs-devel@gnu.org; Fri, 16 Sep 2011 03:23:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Sm6-0004bd-V5 for emacs-devel@gnu.org; Fri, 16 Sep 2011 03:23:52 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:35423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Sm6-0004bV-NS; Fri, 16 Sep 2011 03:23:50 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LRL00300TNGW400@a-mtaout20.012.net.il>; Fri, 16 Sep 2011 10:23:49 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.9.62]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LRL00335TVOC490@a-mtaout20.012.net.il>; Fri, 16 Sep 2011 10:23:49 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:144064 Archived-At: > Date: Thu, 15 Sep 2011 18:02:52 -0400 > From: Richard Stallman > CC: emacs-devel@gnu.org > > When the value is nil, Emacs checks at several places during redisplay > whether some input is available, and if so, it aborts the redisplay > cycle to handle the incoming input. That has the effect of forcing a > full redisplay on the next opportunity, for those frames that were not > completely redisplayed. Here, "full" means that all display > optimizations are wholesale disabled for all windows on the frame. > > That is strange. I wonder why it does that? Because the optimizations rely on the display being up to date, which cannot be assured if redisplay was aborted half way through. The current display engine is very conservative about that, and any of the indications that the display might not be entirely accurate disable most if not all of the optimizations. > In the old days, Emacs would update the display records for each line > that it output, so that the subsequent redisplay would know where it > was starting from. There are no such fine-grained display records in the current display engine, AFAIK. Perhaps that's something that was planned, but never implemented. Or maybe implementing it is very hard with the current display features, I really cannot say. > Over any substantial period, if the commands come so fast that excuting > them leaves no time for redisplay, Emacs should not redisplay at all. > You might describe that by saying "the display gets stuck", but this > is what should happen. Right. But the net effect on the user experience is negative. > . it effectively slows down the keyboard auto-repeat rate (because > events need to wait for the end of redisplay before they are > processed), but only by a small factor, so the user experience is > that Emacs does succeed to keep up. > > I am lost here. The keyboard determines its auto-repeat rate. > Emacs can't slow it down. All it can do is skip redisplays so > as to cope with the commands at the rate they are generated. That's why I said "effectively". The keyboard of course works at its nominal speed, but Emacs lets input events wait in its queue for some short time, thus the rate of event processing is slightly lower than what the keyboard produces. It's hard to time such fast sequences with the existing facilities, but I'm quite sure that letting redisplay optimizations do their best is on balance a win, and only some input events need to wait in the queue before they are processed. IOW, setting this variable non-nil actually helps Emacs to keep up with high-rate input, because the cost of a full redisplay is so much higher.