lazy-lock vs. jit-lock

lazy-lock vs. jit-lock

[Ian Zimmerman]

Can anyone comment on the relative advantages of these kinds of
font-locking?  jit-lock seems to be the default in Emacs 21.4, but I
fount that in some buffers (not necessarily large ones) whole chunks are
left unfontified.  Waiting for them to be "stealthily" fontified also
doesn't help; only font-lock-fontify-buffer does.

Customizing font-lock-support-mode and setting it to lazy-lock-mode
eliminates the problem.  So I'd just like to know what I'm missing
this way.

-- 
A true pessimist won't be discouraged by a little success.

Re: lazy-lock vs. jit-lock

[Peter Dyballa]

Am 29.12.2005 um 08:03 schrieb Ian Zimmerman:

> Can anyone comment on the relative advantages of these kinds of
> font-locking?  jit-lock seems to be the default in Emacs 21.4, but I
> fount that in some buffers (not necessarily large ones) whole chunks 
> are
> left unfontified.  Waiting for them to be "stealthily" fontified also
> doesn't help; only font-lock-fontify-buffer does.
>

jit means just in time -- since modern CPUs are so fast, jit-lock is 
too slow. I think that's jit-lock's story: being helpful on slow 
computers. I seem to remember that it was recommended not to use 
jit-lock any more because it could be removed some day. (I too switched 
off jit-lock some months or years ago.)

--
Greetings

   Pete      <\
              _\     O  _
             |o \  _\\_/-\='
_____________(_)|-(_)  (_)___________________________________

Re: lazy-lock vs. jit-lock

[shreevatsa]

Ian Zimmerman wrote:
> Can anyone comment on the relative advantages of these kinds of
> font-locking?  jit-lock seems to be the default in Emacs 21.4, but I
> fount that in some buffers (not necessarily large ones) whole chunks are
> left unfontified.  Waiting for them to be "stealthily" fontified also
> doesn't help; only font-lock-fontify-buffer does.
>
> Customizing font-lock-support-mode and setting it to lazy-lock-mode
> eliminates the problem.  So I'd just like to know what I'm missing
> this way.
>
> --
You can get rid of the delay by setting jit-lock-stealth-time to 0,
which is what I do.
Looking around on the net seems to suggest that it is lazy-lock that is
obsolete, not jit-lock.
http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/msg00313.html
http://lists.gnu.org/archive/html/help-gnu-emacs/2004-01/msg00626.html

Re: lazy-lock vs. jit-lock

[Ian Zimmerman]

On 29 Dec 2005 07:16:25 -0800, shreevatsa <shreevatsa.public@gmail.com> wrote:
> You can get rid of the delay by setting jit-lock-stealth-time to 0,
> which is what I do.
> Looking around on the net seems to suggest that it is lazy-lock that is
> obsolete, not jit-lock.

You misunderstand.  It's not a delay; the chunks _never_ get fontified, except
manually with M-g M-g.

--
"Political systems do not deal easily
with long term threats,
even if they have a probability of 100%"
James Schlesinger, a former director of the CIA

Re: lazy-lock vs. jit-lock

[rgb]

Ian Zimmerman wrote:
> Can anyone comment on the relative advantages of these kinds of
> font-locking?  jit-lock seems to be the default in Emacs 21.4, but I
> fount that in some buffers (not necessarily large ones) whole chunks are
> left unfontified.  Waiting for them to be "stealthily" fontified also
> doesn't help; only font-lock-fontify-buffer does.

You say waiting doesn't help but I wonder how long you waited.
jit-lock-stealth-time defaults to 16 seconds.
I use these settings on my desktop machine with good results.

(setq jit-lock-chunk-size 10000)
(setq jit-lock-stealth-time 0.5)
(setq jit-lock-stealth-load nil)

Re: lazy-lock vs. jit-lock

[Stefan Monnier]

> jit means just in time -- since modern CPUs are so fast, jit-lock is too
> slow.  I think that's jit-lock's story: being helpful on slow computers.

Huh?  Jit-lock tends to lengthen the time to refresh the screen, so it's
really designed for fast computers where redisplay is fast enough anyway.

> I seem to remember that it was recommended not to use jit-lock any more
> because it could be removed some day.  (I too switched off jit-lock some
> months or years ago.)

Huh?

Jit-lock is the default and is not on the way out *at all*.


        Stefan

Re: lazy-lock vs. jit-lock

[Stefan Monnier]

> Can anyone comment on the relative advantages of these kinds of
> font-locking?  jit-lock seems to be the default in Emacs 21.4, but I
> fount that in some buffers (not necessarily large ones) whole chunks are
> left unfontified.

If those parts are never displayed, then it's "normal" (the default setup
should fontify them stealthily in the background at some time, but that can
be changed and it can take a while anyway, so better not to count on it).
If those parts are displayed and yet they're not fontified it's a bug which
you should report via M-x report-emacs-bug.

> Customizing font-lock-support-mode and setting it to lazy-lock-mode
> eliminates the problem.  So I'd just like to know what I'm missing
> this way.

Lazy-lock has some known bugs (I remember some missing on-screen
fontification using outline-minor-mode, for example), is less efficient, is
not developed any more, and will be marked obsolete in Emacs-22.


        Stefan

Re: lazy-lock vs. jit-lock

[Ian Zimmerman]

On 12/29/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> If those parts are displayed and yet they're not fontified it's a bug which
> you should report via M-x report-emacs-bug.

This is the case.  I'll do a bug report ... but this involves my own mode
and a not exactly mainstream language, so I wonder how far it will get me.
The fact that jit-lock interacts with Emacs C code is not encouraging,
I fear I will be asked to gdb Emacs which I won't.

> Lazy-lock has some known bugs (I remember some missing on-screen
> fontification using outline-minor-mode, for example), >is less efficient<

Can you expand on the last point?  What makes lazy-lock less efficient?

--
"Political systems do not deal easily
with long term threats,
even if they have a probability of 100%"
James Schlesinger, a former director of the CIA

Re: lazy-lock vs. jit-lock

[Stefan Monnier]

>> If those parts are displayed and yet they're not fontified it's a bug which
>> you should report via M-x report-emacs-bug.

> This is the case.  I'll do a bug report ... but this involves my own mode
> and a not exactly mainstream language, so I wonder how far it will get me.

External code is OK.  Of course the more self-contained the recipe, the
better.  Also a good description of the faulty behavior (what you have to do
to cause it, how it manifests itself, ...) is sometimes enough to understand
the problem (without reproducing it ourselves).

> The fact that jit-lock interacts with Emacs C code is not encouraging,
> I fear I will be asked to gdb Emacs which I won't.

We may ask you to debug it, but you don't have to do it.

>> Lazy-lock has some known bugs (I remember some missing on-screen
>> fontification using outline-minor-mode, for example), >is less efficient<

> Can you expand on the last point?  What makes lazy-lock less efficient?

lazy-lock tries to guess which part of the buffer is displayed, based on
various pieces of information.  But those guesses take work and are
necessarily conservative.  jit-lock on the other hand gets this info from
the horse's mouth without any effort.


        Stefan

Re: lazy-lock vs. jit-lock

[Eli Zaretskii]

> Date: Thu, 29 Dec 2005 13:20:11 -0500
> From: Ian Zimmerman <nobrowser@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
> > Lazy-lock has some known bugs (I remember some missing on-screen
> > fontification using outline-minor-mode, for example), >is less efficient<
> 
> Can you expand on the last point?  What makes lazy-lock less efficient?

It is less efficient because it uses ad-hoc mechanisms to detect when
the screen contents has changed (and therefore it's time to maybe
fontify the part that wasn't displayed before).  JIT Lock was written
to take advantage of special redisplay hooks that were introduced in
Emacs 21, so it never has to guess whether portions of the screen were
redrawn.  (By contrast, lazy-lock existed before Emacs 21, and needed
to live without such redisplay hooks.)

Re: lazy-lock vs. jit-lock

[Eli Zaretskii]

> From: Peter Dyballa <Peter_Dyballa@Web.DE>
> Date: Thu, 29 Dec 2005 12:10:29 +0100
> Cc: help-gnu-emacs@gnu.org
> 
> jit means just in time -- since modern CPUs are so fast, jit-lock is 
> too slow. I think that's jit-lock's story: being helpful on slow 
> computers. I seem to remember that it was recommended not to use 
> jit-lock any more because it could be removed some day.

It's the other way around, actually: JIT lock is The One True Way of
doing fontification (although it had some issues in v21.x, resolved
for the next release).

Re: lazy-lock vs. jit-lock

[Ian Zimmerman]

rgb> (setq jit-lock-chunk-size 10000)

This one seems to make the difference - thanks.

The documentation could be improved, I think; it's not clear if this
variable controls fontification of visible or off-screen text,
for example.

-- 
A true pessimist won't be discouraged by a little success.

Re: lazy-lock vs. jit-lock

[Eli Zaretskii]

> From: Ian Zimmerman <nobrowser@gmail.com>
> Date: Thu, 29 Dec 2005 17:07:59 -0800 (PST)
> Cc: help-gnu-emacs@gnu.org
> 
> rgb> (setq jit-lock-chunk-size 10000)
> 
> This one seems to make the difference - thanks.
> 
> The documentation could be improved, I think; it's not clear if this
> variable controls fontification of visible or off-screen text,
> for example.

It controls both.  I fixed the doc string.  Thanks for pointing this
out.