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

[Alan Mackenzie]

Stefan Monnier <monnier@iro.umontreal.ca> wrote on Thu, 22 Jan 2004
18:57:08 GMT:
>> Why jit-lock?

> Lazy-lock was a neat idea to only do fontification on-the-fly: why
> fontify 1MB of code before displaying the first 40 lines ?

> But it was difficult from elisp to do it right: the hooks available to
> lazy-lock to detect when the displayed part of the screen changes and which
> parts of the buffer are currently displayed are not very satisfactory:
> difficult to use (leading to corner cases where fontification is not done
> when it should) and inefficient (lazy-lock is triggered much more often than
> necessary).  This is even more true on XEmacs and old Emacs where one of the
> hooks used by lazy-lock is (or at least was) missing.

Yes.  The commentry at the start of lazy-lock.el details the anguish
experienced by its maintainer (Simon Marshall, perhaps?) in trying to
formulate the Right hooks.  (Who said that Elisp programming isn't like
boxing?  :-)

OK.  So jit-lock was a second design of the same concept, taking
advantage of the experience gained from lazy-lock.

> jit-lock grew out of this: create one new hook designed specifically
> for this job.

fontification-functions?

> 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.  [I reported this, but never
managed to debug it.]  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.
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.]

> The only tradeoff I know of (other than the fact that some of the
> features of lazy-lock have not been ported yet to jit-lock) is that
> lazy-lock has some more knowledge about the intention behind a movement
> because it can tell whether it's been called via
> window-scroll-functions or via buffer-switching, ...

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

Thanks a lot for the elucidation.

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