From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: What is the _essential_ difference between lazy-lock and jit-lock? Date: Mon, 26 Jan 2004 19:03:12 +0000 Organization: muc.de e.V. -- private internet access 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 X-Trace: sea.gmane.org 1075146541 30080 80.91.224.253 (26 Jan 2004 19:49:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Jan 2004 19:49:01 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jan 26 20:48:50 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 1AlCj3-0005my-00 for ; Mon, 26 Jan 2004 20:48:50 +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 1AlChC-00037P-Ho for geh-help-gnu-emacs@m.gmane.org; Mon, 26 Jan 2004 14:46:54 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!npeer.de.kpn-eurorings.net!news.csl-gmbh.net!informatik.tu-muenchen.de!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 61 Original-NNTP-Posting-Host: acm.muc.de Original-X-Trace: marvin.muc.de 1075145456 20351 193.149.49.134 (26 Jan 2004 19:30:56 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: 26 Jan 2004 19:30:56 GMT User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (Linux/2.0.35 (i686)) Original-Xref: shelby.stanford.edu gnu.emacs.help:120433 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:16379 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16379 Stefan Monnier wrote on Fri, 23 Jan 2004 16:29:57 GMT: >> Surely not - Emacs _HUNG_ with stealth fontification, accepting no >> keypresses (apart from a double C-g), and remained in this state >> overnight (> 8 hours). As I said, I reported this [to bug-gnu-emacs, >> 24 Oct 2002, "jit-lock hangs emacs in certain circumstances"], but I >> failed to follow-up RMS's request for a more precise test-case. >> Perhaps I should look into this again. Looking at this bug report >> again, I also said that lazy-lock sometimes hung this way, too. I'm >> sure you're right that it's the tuning of the stealth fontification >> that's pertinent here, not the difference between lazy- and jit-. > I'm pretty sure I've seen this report (although I can't remember it), > but it sounds like a different problem than just tuning, more like a > real bug, probably a bad-regexp in the font-lock settings of a > major-mode (the potentially exponential behavior of the current > regexp-engine is a common problem). This was probably compounded by > the fact that inhibit-quit is set during stealth fontification (input > is polled instead). More info: When Emacs hangs in this manner, a double C-g followed by `fg' often (but not always) brings forth this: : Garbage collection in progress; cannot auto-save now : but will instead do a real quit after garbage collection ends : Abort (and dump core)? (y or n) On replying `n', Emacs frees up again. Left undisturbed it frequently goes back into the hung state. I conjecture that complicated regexps in font-lock settings are somehow creating garbage at a fabulous rate, and jit-lock and the GC are somehow thrashing. Just as soon as jit-lock can be halted and the GC left in peace, things return to OK. I've just noticed something: jit-lock-stealth-load seems to be set by default to 200%. This seems strange. Should this perhaps be 20%. ;-) > This inhibit-quit issue is probably the one we should fix, although > it's a bit tricky to do right (after all, you don't want to leave wrong > highlighting just because the user happened to hit C-g for some > unrelated reason). I think we need a "sledge-hammer" variant of C-g. [ .... ] >> OK. Perhaps for me, simply disabling stealth fontification is the >> right thing. > If you're trying to save power, yes. If not (i.e. if it's to yield the > CPU to other tasks) then you shouldn't need to tune anything (i.e. the > defaults should be improved). OK. > Stefan -- Alan Mackenzie (Munich, Germany) Email: aacm@muuc.dee; to decode, wherever there is a repeated letter (like "aa"), remove half of them (leaving, say, "a").