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: Tue, 28 Oct 2014 20:57:16 -0400 Message-ID: References: <20141026124333.GA4397@acm.acm> <83h9yq4w5g.fsf@gnu.org> <20141026200313.GE4397@acm.acm> <20141026221530.GF4397@acm.acm> <20141027142801.GC2771@acm.acm> <83y4s1317s.fsf@gnu.org> <20141027193839.GD2771@acm.acm> <20141028181003.GA6630@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414544281 14549 80.91.229.3 (29 Oct 2014 00:58:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Oct 2014 00:58:01 +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 Wed Oct 29 01:57:54 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 1XjHaD-00044R-Ob for ged-emacs-devel@m.gmane.org; Wed, 29 Oct 2014 01:57:53 +0100 Original-Received: from localhost ([::1]:42001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjHaD-0007AB-8k for ged-emacs-devel@m.gmane.org; Tue, 28 Oct 2014 20:57:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjHZt-0007A2-IU for emacs-devel@gnu.org; Tue, 28 Oct 2014 20:57:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjHZl-0003j5-Ce for emacs-devel@gnu.org; Tue, 28 Oct 2014 20:57:32 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:45931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjHZd-0003f7-EY; Tue, 28 Oct 2014 20:57:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSSISwnLcgEBAQcCAR+RCAeESwWfEpB9ghGBb4F+IIF2IYJ6AQEB X-IPAS-Result: Au4MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSSISwnLcgEBAQcCAR+RCAeESwWfEpB9ghGBb4F+IIF2IYJ6AQEB X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95468242" Original-Received: from 69-165-143-59.dsl.teksavvy.com (HELO ceviche.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2014 20:57:16 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 4F60A660F3; Tue, 28 Oct 2014 20:57:16 -0400 (EDT) In-Reply-To: <20141028181003.GA6630@acm.acm> (Alan Mackenzie's message of "Tue, 28 Oct 2014 18:10:03 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.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:175952 Archived-At: >> > PageDown key. However, on single PageDowns, the fact that the text is >> > first displayed and only later (~0.1s) fontified could be disturbing to >> > some people. >> I suggested earlier to change jit-lock-defer so that deferral only takes >> place if there's pending input. It might take care of this case. > It doesn't. :-( By "this case" I meant "the case of single page-downs". AFAICT your experiment focused on auto-repeating page-downs, which is a different case. > I've set my jit-lock-defer-time to 0.03s. I think it's better to keep it above 0.1s. > What then happens is that some fontification requests from the scrolling > code (NOT from display) become "non-deferred", and jit-lock fontifies > these chunks. By the time it's done this, there are more PageDown > events in the input queue, so Emacs doesn't get to redisplay anything. > The screen is frozen, but becomes free as soon as the key is released > (within a second). This is inadequate. OK, so it did improve the behavior in the sense that Emacs can now keep up with the scroll commands themselves (tho not the redisplay), so you don't have to wait many seconds when you release the key. But indeed, we have remaining problems. I guess the main one is: If we font-lock during the scroll command and that font-lock takes a while, then by the time we get to redisplay the input queue is not empty any more, so we end up skipping redisplay, so this font-locking was kind of wasted. It would have been better to either not font-lock at all, or to font-lock during redisplay rather than during the scroll command (since that would mean that at least redisplay does happen). Basically if we're in jit-lock and there's input pending, there's a pretty good chance we're not doing redisplay (since redisplay would have been skipped if there was input pending). More specifically, the only case where we can have input pending in jit-lock during redisplay is when the input arrived between the time redisplay started and the time jit-lock gets called, and usually this time is very short. So my idea doesn't work. > I've tried making the C variable redisplaying_p visible in lisp (through > the new function `redisplaying-p') and testing that in the above > condition too, so that we only do undeferred fontification when the request > comes from redisplay. Aside from the objectionableness of never > fontifying for any reason other than redisplay, this doesn't seem to > help matters: auto-repeating PageDown rapidly scrolls all(?) buffer > regions unfontified, but there is the ~0.1s gap between displaying the > last screen and it being fontified. This is also not good. Hmm... the redisplay that happens in response to the last page-down should perform font-lock since there's no input pending. So I don't understand why you see the display unfontified first, followed by fontification 0.1s later. Oh, wait, I guess it's because the previous redisplay had its font-lock deferred so the next 500 bytes were marked as `fontified = defer', so on the "final" redisplay, we may font-lock some additional part of the buffer, but there's a significant part of the visible part of the buffer that's already been marked as `fontified = defer'. I'm beginning to like your C-level hack. Stefan