From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Unfreezing the display during auto-repeated scrolling. Simpler approach. Date: Wed, 29 Oct 2014 21:49:27 -0400 Message-ID: References: <20141027142801.GC2771@acm.acm> <83y4s1317s.fsf@gnu.org> <20141027193839.GD2771@acm.acm> <20141028181003.GA6630@acm.acm> <83wq7j0xqj.fsf@gnu.org> <20141029145211.GB2953@acm.acm> <20141029212525.GD2953@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414633806 736 80.91.229.3 (30 Oct 2014 01:50:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Oct 2014 01:50:06 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 30 02:49:59 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 1XjesB-0001RQ-9M for ged-emacs-devel@m.gmane.org; Thu, 30 Oct 2014 02:49:59 +0100 Original-Received: from localhost ([::1]:50009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjes6-00088Q-Nw for ged-emacs-devel@m.gmane.org; Wed, 29 Oct 2014 21:49:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjerw-00087h-97 for emacs-devel@gnu.org; Wed, 29 Oct 2014 21:49:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xjero-0005ID-QM for emacs-devel@gnu.org; Wed, 29 Oct 2014 21:49:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjerg-0005GQ-PU; Wed, 29 Oct 2014 21:49:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWFgoDBQsLDiYSFBgNJIhLCctyAQEBBwIBH5EIB4RLBbIggW+EFCGCegEBAQ X-IPAS-Result: Au4MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWFgoDBQsLDiYSFBgNJIhLCctyAQEBBwIBH5EIB4RLBbIggW+EFCGCegEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95553795" Original-Received: from 69-165-143-59.dsl.teksavvy.com (HELO pastel.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 21:49:27 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 365147CFF; Wed, 29 Oct 2014 21:49:27 -0400 (EDT) In-Reply-To: <20141029212525.GD2953@acm.acm> (Alan Mackenzie's message of "Wed, 29 Oct 2014 21:25:25 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:176037 Archived-At: >> I think the problem is how to distinguish the two. If we can >> distinguish the two, then we could probably use it in jit-lock-defer. > Every event has a timestamp, doesn't it? If it doesn't, it certainly > ought to! If two successive keyboard events are "the same", and arrive > within kbd-auto-repeat-threshold of eachother, then the first event > should be marked as auto-repeat (assuming it is still in the event > queue). If it's still in the queue, then input-pending-p will return non-nil while it's processed, so jit-lock-defer-when-input-pending would already handle it "right". > Then there needs to be an Fthis_event_is_auto_repeated which remembers > whether the event which became the most recent key-sequence is > auto-repeated. We could indeed try to recognize auto-repeat by looking at the time since the last event, but it seems tricky to make it work well, especially it seems tricky to correctly handle the last such event. >> Another way to look at it: if running CMD required to run the >> fontification functions, then we should not skip the subsequent >> redisplay even if there's input pending (this is based on the assumption >> that running the fontification functions takes the lion's share of >> redisplay time and that running the fontification function during CMD >> means that redisplay probably won't need to run the fontification >> function). Such a heuristic might make the >> jit-lock-defer-when-input-pending work better. > Running display when there's input available is a fairly drastic change > to the command loop. I don't think it's technically drastic. > Also, something, somewhere will need to determine whether the > fontification called for CMD covers the same buffer region as what is > about to be redisplayed. My idea was to assume that it is. At least, it seems unlikely that the two regions would be very far apart. My reasoning is that skipping redisplay should not be done for long periods of time. The reason we want to skip redisplay is to let Emacs perform "real work" instead, but there's a tension where the user also wants to see the intermediate states. Also the gain from skipping redisplay depends on the ratio between "time to run the command" compared to "time to perform redisplay". So if the command took a long time, skipping redisplay provides less gain. So I think we really should force redisplay despite pending input every once in a while. The question is to figure out under which circumstances this should be done, so that those extra redisplays don't slow Emacs substantially overall (i.e. it stays a small fraction of the over processing time) yet they do let the user see intermediate states. Stefan