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: Tue, 26 Apr 2005 12:27:20 +0200 Message-ID: <85r7gxkf3r.fsf@lola.goethe.zz> References: <01c54841$Blat.v2.4$8f503680@zahav.net.il> <01c54917$Blat.v2.4$b975aea0@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 1114512783 25769 80.91.229.2 (26 Apr 2005 10:53:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 26 Apr 2005 10:53:03 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 26 12:53:01 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DQNfP-0004ol-QN for ged-emacs-devel@m.gmane.org; Tue, 26 Apr 2005 12:51:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQNl7-0006M4-5r for ged-emacs-devel@m.gmane.org; Tue, 26 Apr 2005 06:57:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DQNfB-0005QH-20 for emacs-devel@gnu.org; Tue, 26 Apr 2005 06:51:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DQNfA-0005Q0-3K for emacs-devel@gnu.org; Tue, 26 Apr 2005 06:51:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQNf9-00056c-Ku for emacs-devel@gnu.org; Tue, 26 Apr 2005 06:51:31 -0400 Original-Received: from [151.189.21.49] (helo=mail-in-09.arcor-online.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DQNLr-0007CA-PT; Tue, 26 Apr 2005 06:31:35 -0400 Original-Received: from lola.goethe.zz (i5387840E.versanet.de [83.135.132.14]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 9D93157E29; Tue, 26 Apr 2005 12:27:34 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id E40F81C1E25E; Tue, 26 Apr 2005 12:27:20 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Tue, 26 Apr 2005 06:05:41 -0400") 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:36407 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36407 Richard Stallman writes: > > It turns out that vertical-motion was fontifying all the text that > > it moved over. That seems to be easy to fix. > > Did you try my suggestion of customizing jit-lock-defer-time? > > No, because I want to fix this, not work around it. vertical-motion > is a cursor motion function. It should not fontify anything. vertical-motion is a built-in function in `C source code'. (vertical-motion LINES &optional WINDOW) Move point to start of the screen line LINES lines down. If LINES is negative, this means moving up. This function is an ordinary cursor motion function which calculates the new position based on how text would be displayed. The new position may be the start of a line, or just the start of a continuation line. [...] I don't see how vertical-motion can be expected to calculate the new position based on how text would be displayed if it is not allowed to figure out how text would be displayed. So for its correct behavior, it is mandatory to do the font locking. The only exception to that would be if the user would have specified that it is ok to work with unfontified text. One way to do that is to set jit-lock-defer-time. I think it would be reasonable if jit-lock-defer-time (currently defaulting to nil) would instead default to 0, with 0 meaning that font locking will occur without delay before displaying stuff, but not otherwise (maybe that setting already does that, but I have not checked). This would mean that paging back and forth over previously nonfontified stuff would not necessarily lead to the same position, but that still no surprisingly unfontified stuff would show up on the display. But with the current settings, it appears to me that vertical-motion can't reasonably do something different. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum