From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: What is the _essential_ difference between lazy-lock and jit-lock? Date: Thu, 22 Jan 2004 23:37:38 GMT Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <9f3pub.9a.ln@acm.acm> <94lpub.q5.ln@acm.acm> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1074815198 10821 80.91.224.253 (22 Jan 2004 23:46:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2004 23:46:38 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 00:46:35 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AjoWw-0007ZA-00 for ; Fri, 23 Jan 2004 00:46:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjoWG-00084B-1o for geh-help-gnu-emacs@m.gmane.org; Thu, 22 Jan 2004 18:45:52 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!charlie.risq.qc.ca!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-NNTP-Posting-Host: 132.204.24.84 Original-X-Complaints-To: abuse@umontreal.ca Original-X-Trace: charlie.risq.qc.ca 1074814658 132.204.24.84 (Thu, 22 Jan 2004 18:37:38 EST) Original-NNTP-Posting-Date: Thu, 22 Jan 2004 18:37:38 EST Original-Xref: shelby.stanford.edu gnu.emacs.help:120352 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:16296 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16296 >> jit-lock grew out of this: create one new hook designed specifically >> for this job. > fontification-functions? Yes. >> It's simpler, more reliable, faster. > I switched to lazy-lock because jit-lock was causing me problems. > [Admitted, though, that's the Emacs 21.1 version of jit-lock, not the CVS > version.] When I had lots of buffers loaded (by desktop), jit-lock often > caused my Emacs to hang at 100% CPU usage. These have no relationship with the underlying difference. It only has to do with details of how the stealth fontification takes place. On my laptop, I just turn off stealth-fontification with (setq jit-lock-stealth-time nil). > [I reported this, but never managed to debug it.] There's nothing to debug: it's normal, well-understood behavior. Better yet: it's done on purpose. Please switch back to jit-lock and send bug reports so it can be improved. But only after taking steps like (setq jit-lock-stealth-time nil) which are needed for situations where power is not free. Mahybe we can provide better explanations of what can be done for laptops (to save energy) or for machines where the CPU is also needed for other tasks (where stealth fontification might still be OK but should be nicer to other processes: this should be taken care of with jit-lock-stealth-load, but it might not be good enough). > When I was editing a large buffer, continuous > background fontification under jit- gobbled so much CPU power that I > sometimes C-z'ed Emacs to allow (say) a fetchnews run (part of leafnode, > a simple Usenet server) to finish faster. This is on a 166MHz CPU. C-h v jit-lock-stealth- TAB should list a bunch more variables you can tweak to change the amount of CPU used in the background. > Also, sometimes the refontification done after 3 seconds delay > (jit-lock-stealth-time) fouled up an already correctly fontified line. > That is because it yanks that line out of context, not taking account of > the fact it is not "at the top level". [To see this, allow Auto Fill > Mode to split the innards of an @code{...} construct in Texinfo mode. > This problem still exists on 21.3.] font-lock simply does not know how to fontify a @code{...} construct spread on several lines. jit-lock is not to blame for it and lazy-lock will fail similarly in various circumstances because it too simply inherits the shortcomings of font-lock. But maybe jit-lock suffers more often from it, so please send precise bug-reports if you see cases where lazy-lock gets it consistently right whereas jit-lock gets it wrong. As for your problem above: I can't reproduce it with Emacs-CVS, although I can reproduce similar problems if I keep typing after the line was cut by auto-fill-mode. But the problems appears as part of the on-the-fly highlighting, not as part of the refontification that happens after 3s. As for how to fix this problem: (setq font-lock-multiline t) might help, at the cost of a bit slower processing (some have measured a factor 2 difference). >> lazy-lock should be declared obsolete. > I'll need to check out an up to date jit-lock. I have a vague feeling > that lazy- still might work better than jit- on machines with modest > CPUs, particularly when Emacs has to share the processor with other > processes. But I'd need to check out an up to date jit-lock to test > this. That's quite possible, because jit-lock was tuned differently, but this can be changed fairly easily. The difference is not due to the fundamental difference (i.e. which hooks are used) but to different choices of tuning parameters: you can tune lazy-lock to use just as much CPU as jit-lock and vice-versa in most cases. Stefan