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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Indeed.

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

The truth is: I haven't followed closely the introduction of font-core.el
and how font-lock-mode and font-lock-mode-internal interact.  So I'm not
sure which part of font-core.el's behavior is important and which isn't, so
I prefer to fix things from font-lock.el whre I understand the situation
a bit better.

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

That sounds great to me, but that amounts to removing font-core.el, so I'd
need to hear from those who introduced font-core.el.


        Stefan