From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: cc-vars.el Date: Mon, 18 Nov 2002 09:57:15 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200211180057.JAA24537@etlken.m17n.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1037582104 16508 80.91.224.249 (18 Nov 2002 01:15:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Nov 2002 01:15:04 +0000 (UTC) Cc: 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 18DaVB-0004Hs-00 for ; Mon, 18 Nov 2002 02:15:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18DaX9-0005zf-00 for ; Mon, 18 Nov 2002 02:17:03 +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 18DaTu-0006xL-00; Sun, 17 Nov 2002 20:13:42 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18DaEH-0006NB-00 for emacs-devel@gnu.org; Sun, 17 Nov 2002 19:57:33 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18DaEF-0006Mi-00 for emacs-devel@gnu.org; Sun, 17 Nov 2002 19:57:33 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18DaEB-0006LX-00; Sun, 17 Nov 2002 19:57:28 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id gAI0vGk26323; Mon, 18 Nov 2002 09:57:16 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id gAI0vFR18813; Mon, 18 Nov 2002 09:57:15 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id JAA24537; Mon, 18 Nov 2002 09:57:15 +0900 (JST) Original-To: mast@lysator.liu.se, d.love@dl.ac.uk In-reply-to: (message from Dave Love on 17 Nov 2002 22:57:06 +0000) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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:9508 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9508 In article , Dave Love writes: > 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. > What's all this about? I haven't intentionally touched anything > related to cc-mode. Dave, there's nothing wrong with your change. It just revealed a bug of cc-bytecomp-defun. That bug is just fixed by Martin in HEAD as below: 2002-11-16 Martin Stjernholm * progmodes/cc-bytecomp.el (cc-bytecomp-defun): Fixed bug that caused existing function definitions to be overridden by phonies when the bytecomp environment is restored. So, I've just undone my change to cc-vars.el. I confirmed that it is surely fixed now by doing bootstrap. 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. --- Ken'ichi HANDA handa@m17n.org