From: Alan Mackenzie <acm@muc.de>
Cc: Andreas Schwab <schwab@suse.de>,
Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Fight: font-lock.el 1.289 vs. cc-defs.el
Date: Sun, 29 Jan 2006 17:28:02 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.3.96.1060129172112.428F-100000@acm.acm> (raw)
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)
next reply other threads:[~2006-01-29 17:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-29 17:28 Alan Mackenzie [this message]
2006-01-30 4:33 ` Fight: font-lock.el 1.289 vs. cc-defs.el Stefan Monnier
2006-01-30 14:01 ` Alan Mackenzie
2006-01-30 18:46 ` Richard M. Stallman
2006-01-31 14:13 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.3.96.1060129172112.428F-100000@acm.acm \
--to=acm@muc.de \
--cc=monnier@iro.umontreal.ca \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).