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: Thu, 30 Oct 2014 22:09:19 +0000 Message-ID: <20141030220919.GB2721@acm.acm> References: <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; charset=us-ascii X-Trace: ger.gmane.org 1414781337 24001 80.91.229.3 (31 Oct 2014 18:48:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 18:48:57 +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 Fri Oct 31 19:48:50 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 1XkHFi-0000ZX-IF for ged-emacs-devel@m.gmane.org; Fri, 31 Oct 2014 19:48:50 +0100 Original-Received: from localhost ([::1]:41113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkHFi-0002eh-64 for ged-emacs-devel@m.gmane.org; Fri, 31 Oct 2014 14:48:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkE53-0005MJ-Ao for emacs-devel@gnu.org; Fri, 31 Oct 2014 11:26:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xjxux-0004Rf-7U for emacs-devel@gnu.org; Thu, 30 Oct 2014 18:10:19 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:27324 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjxuw-0004HI-UM for emacs-devel@gnu.org; Thu, 30 Oct 2014 18:10:07 -0400 Original-Received: (qmail 13551 invoked by uid 3782); 30 Oct 2014 22:10:02 -0000 Original-Received: from acm.muc.de (pD9518F96.dip0.t-ipconnect.de [217.81.143.150]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 30 Oct 2014 23:10:01 +0100 Original-Received: (qmail 4103 invoked by uid 1000); 30 Oct 2014 22:09:19 -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:176132 Archived-At: Hello, Stefan. On Wed, Oct 29, 2014 at 09:49:27PM -0400, Stefan Monnier wrote: [ ... ] > 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. Let's just say that what I wrote last night was utter rubbish. We cannot handle the last event differently, because when we start handling it, the next event has not yet failed to arrive. My scheme from last night can deliver nothing more than `input-pending-p' already can. > >> 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. Who's going to decide when a "forced" display is to take place? We could, I suppose, set a flag in window_scroll when there's no pending input, and for the command loop to detect this flag and use it to give preference to display over reading keys. But we don't know what command is invoking window_scroll. It might easily be a user written command for which premature display is not wanted. > > 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. I think that's fair enough. > 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. So maybe a timer (?0.2s) could be inserted into the command loop, such that if Emacs has been processing commands for that long since the last redisplay, redisplay will be done in preference to processing the next command. > 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. That's not quite so clear when it's font-locking which is taking the time, since it happens both in command processing and display. > 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. Coming back to scrolling through xdisp.c, merely forcing a redisplay from time to time isn't going to help the slowness of the scrolling. Either eliminating most of the fontification or speeding it up radically (as Eli would prefer) is necessary. > Stefan -- Alan Mackenzie (Nuremberg, Germany).