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: Default of jit-lock-stealth-time Date: Sat, 03 Mar 2007 17:10:55 +0200 Message-ID: References: <85tzxazb8r.fsf@lola.goethe.zz> <85irdi1mar.fsf@lola.goethe.zz> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1172934669 24745 80.91.229.12 (3 Mar 2007 15:11:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2007 15:11:09 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 03 16:11:02 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HNVt0-0005wT-Fg for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 16:11:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNVsz-00014r-VX for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 10:11:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNVso-00014c-MW for emacs-devel@gnu.org; Sat, 03 Mar 2007 10:10:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNVsm-000149-4Z for emacs-devel@gnu.org; Sat, 03 Mar 2007 10:10:49 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNVsl-000145-Vr for emacs-devel@gnu.org; Sat, 03 Mar 2007 10:10:48 -0500 Original-Received: from heller.inter.net.il ([213.8.233.23]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HNVsk-0007jv-0R; Sat, 03 Mar 2007 10:10:46 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-146-218.inter.net.il [80.230.146.218]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id CAI34704 (AUTH halo1); Sat, 3 Mar 2007 17:10:39 +0200 (IST) In-reply-to: <85irdi1mar.fsf@lola.goethe.zz> (message from David Kastrup on Sat, 03 Mar 2007 14:36:28 +0100) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:67257 Archived-At: > Cc: rms@gnu.org, emacs-devel@gnu.org > From: David Kastrup > Date: Sat, 03 Mar 2007 14:36:28 +0100 > > Apart from "pathological" buffers, paging through a file will deliver > font locking fast enough to follow the user action Where ``fast enough'' means what, precisely? > In contrast, left alone to jit-lock-stealth-time=16, Emacs will > eventually turn to eating 100% of CPU time (not 1-3%) How can this happen? JIT-lock is supposed to fontify at most jit-lock-chunk-size characters (500 by default), and then refrain from fontification for at least jit-lock-stealth-nice seconds (0.5 by default). How can Emacs take 100% of CPU with these defaults? Maybe there's a bug? How much time do you need to wait until Emacs starts using 100% of CPU on your machine? I didn't see that, but maybe I didn't wait long enough. Also, did you try looking at the percentage of CPU taken by each application, when the CPU consumption hits 100%, and if you did, was Emacs indeed consuming 100% or thereabouts at that time? > That does not mean that the problematic files will page through > without noticeable delay when I go through them by hand: they tend to > react sluggishly to editing. These delays and sluggishness were what I meant when I talked about annoyances. I don't like them. > I would consider stealth fontification completely useless as long as > the computer can keep up with the user, which appears to be the case > for your usage. In that case, investing the power when it is actually > needed seems by far the sanest choice. David, your opinion was heard, loud and clear, several times already. There's no need to reiterate it. Doing so just wastes bandwidth. For my part, I can say that investing a small fraction of CPU power when none is used is by far wiser than annoying the user with redisplay delays, if those are noticeable.