[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fight: font-lock.el 1.289 vs. cc-defs.el
From: |
Stefan Monnier |
Subject: |
Re: Fight: font-lock.el 1.289 vs. cc-defs.el |
Date: |
Sun, 29 Jan 2006 23:33:41 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
> 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