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: Unfreezing the display during auto-repeated scrolling. Simpler approach. Date: Wed, 29 Oct 2014 21:25:25 +0000 Message-ID: <20141029212525.GD2953@acm.acm> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1414618008 20558 80.91.229.3 (29 Oct 2014 21:26:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Oct 2014 21:26:48 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 29 22:26:42 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 1XjalM-0000Pi-AX for ged-emacs-devel@m.gmane.org; Wed, 29 Oct 2014 22:26:40 +0100 Original-Received: from localhost ([::1]:49152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjalL-0004xT-Tc for ged-emacs-devel@m.gmane.org; Wed, 29 Oct 2014 17:26:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjakx-0004tB-F3 for emacs-devel@gnu.org; Wed, 29 Oct 2014 17:26:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xjako-0001VP-RI for emacs-devel@gnu.org; Wed, 29 Oct 2014 17:26:15 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:10835 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjako-0001Uq-HI for emacs-devel@gnu.org; Wed, 29 Oct 2014 17:26:06 -0400 Original-Received: (qmail 49560 invoked by uid 3782); 29 Oct 2014 21:26:05 -0000 Original-Received: from acm.muc.de (pD9519282.dip0.t-ipconnect.de [217.81.146.130]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 29 Oct 2014 22:26:03 +0100 Original-Received: (qmail 5497 invoked by uid 1000); 29 Oct 2014 21:25:25 -0000 Content-Disposition: inline In-Reply-To: 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:176029 Archived-At: Hello, Stefan. On Wed, Oct 29, 2014 at 12:59:26PM -0400, Stefan Monnier wrote: > > An approach I haven't tried yet would be to use the existing scrolling > > functionality for discreet key presses, changing to > > nilled-out-fontification-functions when the keystrokes are coming in at > > auto-repeat rates. > 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). 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. Then a scrolling command (or similar) can test this-event-is-auto-repeated to discover whether or not it's got enough breathing space to do something lengthy (such as invoking functions which want to fontify with fontification-functions intact). Or something like that. > More specifically, your jit-lock-defer experiment showed that the > problem is that to get smooth scrolling, we need to skip fontification > during the scroll even though there's no input pending (because the > next repetition hasn't arrived yet). Yes. > 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. 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. > Stefan -- Alan Mackenzie (Nuremberg, Germany).