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: Fri, 23 Jan 2004 10:36:15 +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 1074854842 17527 80.91.224.253 (23 Jan 2004 10:47:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2004 10:47:22 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 11:47:14 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 1AjyqI-00016s-00 for ; Fri, 23 Jan 2004 11:47:14 +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 1Ajyos-0004Wb-6c for geh-help-gnu-emacs@m.gmane.org; Fri, 23 Jan 2004 05:45:46 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!bloom-beacon.mit.edu!npeer.de.kpn-eurorings.net!newsfeed.stueberl.de!news.space.net!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 113 Original-NNTP-Posting-Host: acm.muc.de Original-X-Trace: marvin.muc.de 1074853917 18947 193.149.49.134 (23 Jan 2004 10:31:57 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: 23 Jan 2004 10:31:57 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:120359 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:16303 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16303 Stefan Monnier wrote on Thu, 22 Jan 2004 23:37:38 GMT: >> 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). OK. >> [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. 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-. > 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). The font lock support modes are not documented. In fact, the reason I posted my question last night was because I was considering contributing this documentation myself. Until your last post, I wasn't really aware that I could tune jit-lock to my system. I sort of knew, but wasn't aware. Tuning jit-lock is very difficult. Using customize, even after finding the Jit Lock customize group (difficult in itself), there is a bewildering collection of options to set. (I mean here bewildering to _me_, and I think I have a better grasp of font lock than typical Emacs users.) It would seem that a detailed understanding of how jit-lock works is a prerequisite for setting these options intelligently. This is surely not a good thing. Perhaps what is wanted is a command like `(font-lock-tune-font-lock 'low-powered-workstation)' by which users could select from amongst several pre-defined tunings, somewhat analogous to CC Mode's `c-set-style'. >> 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. OK. Perhaps for me, simply disabling stealth fontification is the right thing. >> 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. You're right there. jit-lock mis-fontifies by stealth, immediately after the line is split by Auto Fill Mode, whereas lazy-lock doesn't (even after 30 seconds). However, as soon as one types a further character on the newly split line, the fontification goes wrong (in all support modes, or none). This isn't an important difference between jit- and lazy-. Sorry. > 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). YES, YES YES!!!! font-lock-multiline does the trick! [Emacs 21.3]. I don't understand how, or why, but it works. Thanks! [ .... ] > 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").