[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the _essential_ difference between lazy-lock and jit-lock?

From: Stefan Monnier
Subject: Re: What is the _essential_ difference between lazy-lock and jit-lock?
Date: Fri, 23 Jan 2004 16:29:57 GMT
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

> 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).

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.

> 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.

That would be extremely welcome.

> 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'.

I think the defaults can be improved to make manual tuning rare.  In most
cases, it should be possible for Emacs to automatically detect it's using
too much CPU time and back-off.  The only manual setting that seems
necessary is "save energy" (or is there some way for Emacs to detect
whether the computer is running on battery?) which should boild down to
turning off jit-lock-stealth-time, although it should be done in a more
obvious way (maybe a global `save-energy' variable which lazy-lock and
jit-lock and others can use).

>>> 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.

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]