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

[Stefan Monnier]

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