From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: C-n is very slow in Font-Lock mode Date: Wed, 27 Apr 2005 12:19:27 +0300 Message-ID: <01c54b0a$Blat.v2.4$5b6307a0@zahav.net.il> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1114594098 17205 80.91.229.2 (27 Apr 2005 09:28:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Apr 2005 09:28:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 27 11:28:15 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DQipU-0003SI-EG for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2005 11:27:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQivN-00038x-Qy for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2005 05:33:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DQivB-00038r-TD for emacs-devel@gnu.org; Wed, 27 Apr 2005 05:33:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DQiv9-00038D-0B for emacs-devel@gnu.org; Wed, 27 Apr 2005 05:33:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQiv8-0002Py-Rr for emacs-devel@gnu.org; Wed, 27 Apr 2005 05:33:26 -0400 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DQinI-00081n-Tg; Wed, 27 Apr 2005 05:25:21 -0400 Original-Received: from zaretski (IGLD-80-230-41-251.inter.net.il [80.230.41.251]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id EFZ01099 (AUTH halo1); Wed, 27 Apr 2005 12:21:08 +0300 (IDT) Original-To: David Kastrup X-Mailer: emacs 22.0.50 (via feedmail 8 I) and Blat ver 2.4 In-reply-to: <85hdhtf8ou.fsf@lola.goethe.zz> (message from David Kastrup on Wed, 27 Apr 2005 00:57:05 +0200) 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:36437 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36437 > Cc: emacs-devel@gnu.org > From: David Kastrup > Date: Wed, 27 Apr 2005 00:57:05 +0200 > > Without looking at the code, it would be my guess that it would > currently run immediately after redisplay, whereas my suggestion for > jit-lock-defer-time=0 semantics would be that it be run immediately > before redisplay. I'm not sure what that means. You _are_ aware that, when you scroll thru text with C-n or C-v, there's almost nothing going on in Emacs _except_ redisplay, yes? That is, all C-n does is move point one line; the rest is redisplay's job, including fontification. (The single most important new aspect of JIT lock as opposed to the old lazy-lock and its ilk was that JIT lock uses special hooks of the display engine, whereas the old, pre-v21 redisplay didn't have such hooks, and so lazy-lock needed to jump through the hoops to hook into every possible method of changing the displayed text.) So when you are saying ``before redisplay'', what exactly do you mean? Redisplay begins by computing the ``desired glyph matrix'', which is an internal representation of what should be on the screen; surely, before this happens, there's no way we could fontify the right portion of the text, since we have no idea what that portion is. > > And fontification of the visible portion will take time during which > > one still sees unfontified text, anyway. > > Not if it happens before redisplay. [...] > > It would possibly make sense to implement this distinction in the > context of run-with-idle-timer, and then let jit-lock-defer-time just > use it by defaulting to -1. Idle timers run when Emacs is idle, which by definition is _after_ redisplay did its job. So I think you are talking about some nw mechanism, which has nothing to do with how jit-lock-defer-time works now. > Again: I have not looked at the code. Well, perhaps you should.