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