From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Fight: font-lock.el 1.289 vs. cc-defs.el Date: Sun, 29 Jan 2006 17:28:02 +0000 (GMT) Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1138558155 30026 80.91.229.2 (29 Jan 2006 18:09:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 29 Jan 2006 18:09:15 +0000 (UTC) Cc: Andreas Schwab , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 29 19:09:12 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F3Gz7-0000xL-Eo for ged-emacs-devel@m.gmane.org; Sun, 29 Jan 2006 19:09:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F3H21-0007ky-Pm for ged-emacs-devel@m.gmane.org; Sun, 29 Jan 2006 13:12:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F3GK1-0003O6-I5 for emacs-devel@gnu.org; Sun, 29 Jan 2006 12:26:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F3GJn-0003KB-Ck for emacs-devel@gnu.org; Sun, 29 Jan 2006 12:26:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F3GJn-0003K8-6V for emacs-devel@gnu.org; Sun, 29 Jan 2006 12:26:27 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F3GHw-0000bl-C3 for emacs-devel@gnu.org; Sun, 29 Jan 2006 12:24:33 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id RAA00854; Sun, 29 Jan 2006 17:28:04 GMT X-Sender: root@acm.acm Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49684 Archived-At: 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)