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 14:59:52 +0300 Message-ID: <01c54b20$Blat.v2.4$c54e3200@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> <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> 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 1114603462 14130 80.91.229.2 (27 Apr 2005 12:04:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Apr 2005 12:04:22 +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:04:18 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DQlGL-0003nJ-62 for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2005 14:03:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQlME-0003tY-QJ for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2005 08:09:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DQlGz-00026c-AS for emacs-devel@gnu.org; Wed, 27 Apr 2005 08:04:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DQlGt-00024G-QY for emacs-devel@gnu.org; Wed, 27 Apr 2005 08:04:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQlGq-00023c-NI for emacs-devel@gnu.org; Wed, 27 Apr 2005 08:04:02 -0400 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DQlIW-00012d-EO; Wed, 27 Apr 2005 08:05:44 -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 EFZ35523 (AUTH halo1); Wed, 27 Apr 2005 15:01:37 +0300 (IDT) Original-To: David Kastrup X-Mailer: emacs 22.0.50 (via feedmail 8 I) and Blat ver 2.4 In-reply-to: <85d5sge9qc.fsf@lola.goethe.zz> (message from David Kastrup on Wed, 27 Apr 2005 13:32:11 +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:36446 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36446 > Cc: emacs-devel@gnu.org > From: David Kastrup > Date: Wed, 27 Apr 2005 13:32:11 +0200 > > >> We are talking about the situation where the input is coming in faster > >> than Emacs can process it. > > > > See, we don't really know that. Whether this is true or not, > > depends on several unknown factors, like the rate of keyboard > > auto-repeat on the user's machine vs the time it takes Emacs on that > > machine, with that CPU and display type/toolkit to perform > > redisplay. > > > > In my experience, movement with C-n gives Emacs enough time to > > update the display. > > The last time I looked, this thread was about Emacs not being fast > enough to update the display. 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. > > 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. 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): 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, while setting it to something like 0.2 would make paging as fast as without font lock. 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?