Re: hi-lock-mode doesn't work with emacs -Q.

[Alan Mackenzie]

Hi, Stefan!

On Mon, Jun 11, 2007 at 04:25:14PM -0400, Stefan Monnier wrote:
> > .  Enable hi-lock-mode and make "foo" a highlightable pattern:

> >     M-x hi-lock-mode
> >     C-x w h foo<CR><CR>    ; accept the default hi-yellow face.

> > .  This highlights the "foo" yellow, as expected.  At the end of the
> > line, type:

> >     foo

> > .  This new "foo" doesn't get highlighted.  It should be.

> I believe the patch below fixes the problem without making things worse
> and without requiring changes to hi-lock.el.


>         Stefan


> --- font-lock.el      08 May 2007 11:55:52 -0400      1.317
> +++ font-lock.el      11 Jun 2007 15:56:01 -0400      
> @@ -698,6 +698,14 @@
>        ;; contain the new keywords.
>        (font-lock-update-removed-keyword-alist mode keywords how))
>       (t
> +         (when (and font-lock-mode
> +                    (not (or font-lock-keywords font-lock-defaults)))
> +           ;; The major mode has not set any keywords, so when we enabled
> +           ;; font-lock-mode it only enabled the font-core.el part, not the
> +           ;; font-lock-mode-internal.  Try again.
> +           (font-lock-mode -1)
> +           (set (make-local-variable 'font-lock-defaults) '(nil t))
> +           (font-lock-mode 1))
>        ;; Otherwise set or add the keywords now.
>        ;; This is a no-op if it has been done already in this buffer
>        ;; for the correct major mode.

That patch will certainly make hi-lock work properly.  However, are you
sure there is nothing else which can necessitate the enabling of the
after-change function?  Also, there is nothing in the documentation
forbidding a hacker from changing font-lock-keywords directly, which
would cause font-lock to fail in other circumstances.

My first thought was that instead of switching Font Lock fully off then
fully on again, as you are proposing in your patch, we should just call
font-lock-mode-internal.  But this clashes with the
font-lock-default-function mechanism - font-lock-keywords cannot know
that the current f-l-default-function has used this
"ignition/starter-motor" mechanism.

It seems to me that this two-stage initialisation of f-l-mode brings a
lot of complexity for very little gain - The f-l-change-function can
never execute in the background and consume vast amounts of CPU usage.
It can only ever be called for the current buffer, and if Font Lock is
enabled, yet f-l-keywords hasn't been set, its runtime is negligible
anyway.

Or is there some good reason for this optimisation that I'm missing?  If
not, I suggest that you simply remove this optimisation and always
install the after-change function when f-l-mode is started.

-- 
Alan.