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

[Alan Mackenzie<none@example.invalid>]

Stefan Monnier <monnier@iro.umontreal.ca> 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").