From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: C-n is very slow in Font-Lock mode Date: Wed, 27 Apr 2005 14:23:08 +0200 Message-ID: <85zmvkcssz.fsf@lola.goethe.zz> References: <01c54841$Blat.v2.4$8f503680@zahav.net.il> <01c54917$Blat.v2.4$b975aea0@zahav.net.il> <01c54a8a$Blat.v2.4$9d6aeda0@zahav.net.il> <85mzrlgqws.fsf@lola.goethe.zz> <01c54ab1$Blat.v2.4$91328080@zahav.net.il> <85hdhtf8ou.fsf@lola.goethe.zz> <01c54b0a$Blat.v2.4$5b6307a0@zahav.net.il> <85ll74eesa.fsf@lola.goethe.zz> <01c54b12$Blat.v2.4$78afaa40@zahav.net.il> <85d5sge9qc.fsf@lola.goethe.zz> <01c54b20$Blat.v2.4$c54e3200@zahav.net.il> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1114606144 23408 80.91.229.2 (27 Apr 2005 12:49:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Apr 2005 12:49:04 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 27 14:49:01 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DQlxn-0000pe-EX for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2005 14:48:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQm3i-0003Rs-Ru for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2005 08:54:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DQm3a-0003Rn-BY for emacs-devel@gnu.org; Wed, 27 Apr 2005 08:54:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DQm3X-0003RB-RR for emacs-devel@gnu.org; Wed, 27 Apr 2005 08:54:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQm3X-0003NN-M8 for emacs-devel@gnu.org; Wed, 27 Apr 2005 08:54:19 -0400 Original-Received: from [151.189.21.42] (helo=mail-in-02.arcor-online.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DQm2X-0004vi-6c; Wed, 27 Apr 2005 08:53:17 -0400 Original-Received: from lola.goethe.zz (i53878B5E.versanet.de [83.135.139.94]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 79AB9139884; Wed, 27 Apr 2005 14:49:05 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 918D31C2FE29; Wed, 27 Apr 2005 14:23:09 +0200 (CEST) Original-To: Eli Zaretskii In-Reply-To: <01c54b20$Blat.v2.4$c54e3200@zahav.net.il> (Eli Zaretskii's message of "Wed, 27 Apr 2005 14:59:52 +0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:36449 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36449 "Eli Zaretskii" writes: > Maybe it was, I just am not sure. Richard said "C-n is very slow" > and gave an example of invoking C-n with a large numeric argument. > The example would cause only one redisplay: at the end of movement, > regardless of the rate input is coming in. > That is not the only situation that jit-lock-defer-time was > introduced to deal with, see below. Sure. Making it do something sensible for one more application does not seem like a bad idea. >> > jit-lock-defer-time non-nil works by disabling fontification >> > altogether until Emacs is idle. If fontification is not >> > disabled, you yourself explained that vertical-motion _must_ >> > fontify to keep its calculations accurate. >> >> It seems I am a complete failure at conveying my meaning. > > Or I am a complete failure at understanding it. > >> I was arguing for a setting where vertical-motion is allowed to >> keep its calculations inaccurate with regard to font locking. > > And I was trying to say that AFAIK currently there's no reliable way > of deferring fontifications until just before the screen is redrawn. Well, I am afraid that I was completely unable to get that point from what you have written. I already said that I was not familiar with the code, but described a _behavior_ that I would consider useful. Now instead of arguing in various and, to my mind contradictory ways, about the usefulness of the behavior, it would have been easier to just say "Emacs can't do this at the current point of time, for this and that reason". Then one can think about whether the required effort would be worth investing or not. There is unfortunately some relevancy with regard to the release: there was quite a bit of agreement that it would be a generally desirable thing if Emacs had global fontlocking on by default, and one of the preconditions was that it would not cause serious regressions in usability/performance. So we need to figure out whether we can make do with changed settings and minor changes, and if not, whether the overall cost of enabling font locking by default can be considered tolerable nevertheless. > What you suggest will perhaps work in the single example given by > Richard (and even then it requires some changes in the C code), but > I see difficulty applying it to other situations. For example, > consider the case where I press and hold C-v (a not-so-uncommon way > of paging quickly through a large buffer): Yes. > with your suggestion, unless Emacs never redraws a screen until I > lift my fingers (a rare case with a reasonably fast machine and > reasonably sized windows), the paging would be as slow as with > jit-lock-defer-time set to nil, I don't really think so, since while it is redrawing and font locking a screenful of material, additional keypresses keep pouring in and will be processed in one batch before the next redraw is attempted. So the paging should get more jumpy, but the progress should not noticeably slow. Things are different with input devices that block autorepeat as long as the input is not being processed/queued. In that case, indeed the paging will be as slow as possible. > In other words, the fact that Emacs becomes idle is a clear sign > that the screen was updated and the displayed text must now be > fontified. In your suggestion, what would be such a clear sign? If Emacs is idle and there is nothing in the keyboard input queue waiting to be processed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum