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: Re: Fight: font-lock.el 1.289 vs. cc-defs.el Date: Mon, 30 Jan 2006 14:01:44 +0000 (GMT) Message-ID: References: <87fyn62vre.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1138639456 23155 80.91.229.2 (30 Jan 2006 16:44:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2006 16:44:16 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 30 17:44:11 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 1F3c7z-0006X5-N1 for ged-emacs-devel@m.gmane.org; Mon, 30 Jan 2006 17:43:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F3cAx-0001g0-IE for ged-emacs-devel@m.gmane.org; Mon, 30 Jan 2006 11:46:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F3a9O-0006c4-Ly for emacs-devel@gnu.org; Mon, 30 Jan 2006 09:37:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F3a9L-0006aZ-GA for emacs-devel@gnu.org; Mon, 30 Jan 2006 09:37:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F3a9K-0006a4-SB for emacs-devel@gnu.org; Mon, 30 Jan 2006 09:36:58 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F3a7c-0000ye-H1 for emacs-devel@gnu.org; Mon, 30 Jan 2006 09:35:14 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id OAA00783; Mon, 30 Jan 2006 14:01:45 GMT X-Sender: root@acm.acm Original-To: Stefan Monnier In-Reply-To: <87fyn62vre.fsf-monnier+emacs@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:49755 Archived-At: On Sun, 29 Jan 2006, Stefan Monnier wrote: >> 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. The alternative is CC Mode not working properly (or at all) in some versions. For example, but for a similar test and correction, it would fail in Emacs 21.[1234] because of a bug in regexp-opt-depth. These old bugs in the XEmacs and Emacs cores have only been fixed in recent versions, not in all the versions currently in the field. It's a core objective of CC Mode to be compatible with all recent versions of both Emacsen. >> 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. There is indeed! There's vim, Eclipse, CodeWrite, MS Visual Studio, .... Actually, thinking about it, it would be better to test explicitly for XEmacs in this case. That's what I'll do. >> 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. OK. Presumably that code has since been corrected. But as a general point, CC Mode (and presumably other packages) is going to be calling random functions within the (X)Emacs core to detect the inevitable buggy versions. There is a danger that other packages also test for this bug in font-lock-compile-keywords, causing these packages to fail. >> 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 -- Alan.