From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kifer@cs.sunysb.edu (Michael Kifer) Newsgroups: gmane.emacs.devel Subject: Re: lisp/ChangeLog coding system Date: Sat, 27 Apr 2002 19:05:36 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200204272305.TAA16810@sbcs.cs.sunysb.edu> References: <200204272241.g3RMfqI05559@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1019949150 24057 127.0.0.1 (27 Apr 2002 23:12:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 27 Apr 2002 23:12:30 +0000 (UTC) Cc: gerd@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.33 #1 (Debian)) id 171bMk-0006Fu-00 for ; Sun, 28 Apr 2002 01:12:30 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 171bQ5-00048W-00 for ; Sun, 28 Apr 2002 01:15:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 171bMV-000148-00; Sat, 27 Apr 2002 19:12:15 -0400 Original-Received: from sbcs.cs.sunysb.edu ([130.245.1.15]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 171bK5-0000xI-00; Sat, 27 Apr 2002 19:09:45 -0400 Original-Received: from sbkifer (sbkifer [130.245.1.35]) by sbcs.cs.sunysb.edu (8.9.3/8.9.3) with SMTP id TAA16810; Sat, 27 Apr 2002 19:05:35 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: "Richard Stallman" of Sat, 27 Apr 2002 16:41:52 MDT <200204272241.g3RMfqI05559@aztec.santafe.edu> Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3338 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3338 > Michael, somehow you recoded lisp/ChangeLog with your latest change > from its specified coding system iso-2022-7bit to something else. > > Michael, if you can figure out precisely how this happened, it might > lead us to a way to make the Mule features more robust. Many users > might benefit from that. So I think it is worth spending some time to > try to reconstruct how this happened. I didn't notice any problems. However, if there were, it is due to the fact that I had to change X selection coding system to latin-1, because there is a bug in the default coding system (which used to be compound-text-with-extensions, but I now see it no longer is) for X selections. (There was a discussion about this a week ago and Eli traced it to that X selection coding system bug).