From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: cc-vars.el Date: 18 Nov 2002 19:51:54 +0000 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200211180057.JAA24537@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037649856 17492 80.91.224.249 (18 Nov 2002 20:04:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Nov 2002 20:04:16 +0000 (UTC) Cc: mast@lysator.liu.se, rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18Ds7x-0004Xj-00 for ; Mon, 18 Nov 2002 21:04:13 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18DsAK-0007tF-00 for ; Mon, 18 Nov 2002 21:06:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Ds9I-00019q-00; Mon, 18 Nov 2002 15:05:36 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18DrzP-0006tY-00 for emacs-devel@gnu.org; Mon, 18 Nov 2002 14:55:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18DrwG-00060T-00 for emacs-devel@gnu.org; Mon, 18 Nov 2002 14:52:13 -0500 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Drw9-0005wA-00; Mon, 18 Nov 2002 14:52:02 -0500 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 18Drw2-0005cD-00; Mon, 18 Nov 2002 19:51:54 +0000 Original-To: Kenichi Handa Original-Lines: 55 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9528 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9528 Kenichi Handa writes: > But, Richard is against cc-bytecomp-defun. He wrote: > > Richard Stallman writes: > > + 2002-11-14 Kenichi Handa > > + > > + * progmodes/cc-vars.el: Don't cc-bytecomp-defun char-table-p. > > + > > > I think that is the right fix--this cc-bytecomp-defun is a bad kludge. > > I am thinking that maybe we should get rid of it because it is so > > risky. > > > I had undone Dave's change in set-buffer-file-coding-system to fix this, > > but I restored that change today after concluding that cc-bytecomp-defun > > is the real culprit. > > Martin, could you discuss this issue with Richard from now > on. I don't have any strong opinion on this issue. I still don't understand how what I did affected this, but then I didn't try to use cc-mode in the bootstrapped result. However, I strongly agree with rms. I didn't realize cc-mode was doing that, but I'm sure it shouldn't. I've previously fixed Gnus and W3 to avoid special compilation mechanisms like that. Apart from being probably unsuitable for installing in Emacs, they actually hid bugs. There are typically still some compilation warnings if you do portability stuff cleanly, but they're not usually excessive. Changes to the compiler would help, e.g. to avoid warnings from (unless (fboundp 'fred) (define fred ...)) A change for that I once suggested greatly reduced the noise and I don't think it's a big issue to re-write a few things to forms such a compiler check would be documented to recognize. I see a comment in cc-bytecomp implying that compilation is supposed to produce byte code that's portable between Emacs and XEmacs, but that's a lost cause. They are (now) basically incompatible, e.g. XEmacs byte code can crash Emacs if you force it to be loaded. This means that the compiler can reasonably eliminate code conditional on `(featurep 'xemacs)', for instance, reducing spurious warnings again and perhaps improving efficiency in a few cases. I also think it's unwise to try to support ancient versions of (X)Emacs. That just makes life difficult and takes resources that could be put into improvements for current versions, especially taking advantage of new features. Sorry if that sounds like just a gripe, but it's from a fair amount of experience. :-/