Fight: font-lock.el 1.289 vs. cc-defs.el

[Alan Mackenzie]

Hi, Emacs!

In font-lock.el V1.289, the following check was introduced into
font-lock-compile-keywords:

--- emacs/lisp/font-lock.el     2005/12/22 16:09:32     1.288
+++ emacs/lisp/font-lock.el     2005/12/30 04:38:52     1.289
@@ -1507,6 +1507,13 @@
 `font-lock-keywords' doc string.
 If REGEXP is non-nil, it means these keywords are used for
 `font-lock-keywords' rather than for `font-lock-syntactic-keywords'."
+  (if (not font-lock-set-defaults)
+      ;; This should never happen.  But some external packages sometimes
+      ;; call font-lock in unexpected and incorrect ways.  It's important to
+      ;; stop processing at this point, otherwise we may end up changing the
+      ;; global value of font-lock-keywords and break highlighting in many
+      ;; other buffers.
+      (error "Font-lock trying to use keywords before setting them up"))
   (if (eq (car-safe keywords) t)
       keywords
     (setq keywords

This inconveniences CC Mode, thusly:

CC Mode calls (font-lock-compile-keywords "\\<\\>") at initialisation, to
test for a bug in middle aged XEmacsen which splatted font-lock-keywords.
The new check in V1.289 causes CC Mode to bail out with an error.

Andreas Schwab patched a work-around into cc-defs.el V1.38, placing a
condition-case around the call.  This seems suboptimal: If some error
occurs whilst calling some Font Lock function, we definitely want to know
about it.

A better(??) kludge would be for cc-defs to bind font-lock-set-defaults
to non-nil before calling (font-lock-compile-keywords "\\<\\>"), but this
is really ghastly coding practise.

I'm asking that this change to font-lock.el be reconsidered, though I
admit I don't know the problem it fixes.  Might a better solution be
(make-variable-buffer-local 'font-lock-keywords)?  That variable surely
_cannot_ have a meaningful global value - or can it?

--
Alan Mackenzie (Munich, Germany)