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

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

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

I must admit I have very little sympathy for ugly code that tries to work
around old bugs that've been fixed a long time ago.

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

So a better/real fix would be to remove this workaround altogether and if
someone complains, tell him to fix it himself or upgrade his old XEmacs or
stick to an old cc-mode.  Plenty of choice left.

> I'm asking that this change to font-lock.el be reconsidered, though I
> admit I don't know the problem it fixes.

It help(s|ed) detect faulty code, more precisely code that used font-lock
code without first setting up font-lock variables.  I guess with the recent
changes that force font-lock-fontify-buffer and font-lock-fontify-region to
setup the variables, this is not needed any more, since those were the
main culprits.

> Might a better solution be (make-variable-buffer-local
> 'font-lock-keywords)?

That would only hide the problem.  Calling font-lock-set-defaults does a lot
more than make this variable local to a buffer.

> That variable surely _cannot_ have a meaningful global value - or can it?

Indeed.


        Stefan