From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/47544 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: coding-system for drafts Date: Tue, 05 Nov 2002 13:23:34 +0100 Organization: University of Dortmund, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <84smyggq7t.fsf@crybaby.uni-duisburg.de> References: <84adl2llk6.fsf@crybaby.uni-duisburg.de> <84y98htj5s.fsf@crybaby.uni-duisburg.de> <20021103003409A.1000@pine.kuee.kyoto-u.ac.jp> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036499020 10950 80.91.224.249 (5 Nov 2002 12:23:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2002 12:23:40 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1892k7-0002qS-00 for ; Tue, 05 Nov 2002 13:23:39 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1892kf-0004x7-00; Tue, 05 Nov 2002 06:24:13 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 05 Nov 2002 06:24:58 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id GAA05860 for ; Tue, 5 Nov 2002 06:24:41 -0600 (CST) Original-Received: (qmail 2643 invoked by alias); 5 Nov 2002 12:23:42 -0000 Original-Received: (qmail 2638 invoked from network); 5 Nov 2002 12:23:41 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by gnus.org with SMTP; 5 Nov 2002 12:23:41 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 1892qf-0002Ap-00 for ; Tue, 05 Nov 2002 13:30:25 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 77 Original-NNTP-Posting-Host: crybaby.uni-duisburg.de Original-X-Trace: quimby.gnus.org 1036499425 8358 134.91.30.116 (5 Nov 2002 12:30:25 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 5 Nov 2002 12:30:25 GMT User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) Cancel-Lock: sha1:I5kMKgYs7iBDrwMcv0O0eKq60y8= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:47544 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:47544 TSUCHIYA Masatoshi writes: > I think that your solution consists of two parts: > > (1) A new draft which has a coding cookie is decoded in the coding > system specified in its cookie. > (2) An old draft which lacks a coding cookie is decoded in the value > of message-draft-coding-system. That's right. There is also the encoding part, though. I don't have an opinion which coding system should be used for new drafts (but the safe iso-2022-7bit seems good), but whatever is chosen should be put in the coding cookie so that subsequent readings of the file with do the right thing. > In this solution, the default value of message-draft-coding-system > will be stayed in order to keep backwards compatibility. Do I have a > proper understanding? Well, for new auto-save files a different encoding can be chosen. Only the encoding for reading the old auto-save files must remain the same. Silly me, I thought that one could just hard-code `emacs-mule' as the encoding for reading old files, but that would break if people have changed message-draft-coding-system. As you can see, I haven't thought about it very thoroughly. > Mr. Yamaoka and I think that emacs-mule is not suitable for the > default value of message-draft-coding-system. The main ground of our > argument is that emacs-mule is not compatible between emacsen. For > example, > > (a) emacs-mule is not compatible between Emacs20 and Emacs21, > because some charsets are supported by Emacs21 but are not > supported by Emacs20. > (b) emacs-mule is not compatible between Emacs20 with Mule-UCS and > Emacs20 without Mule-UCS. Charsets related to Unicode are not > defined in Emacs20 without Mule-UCS. > (c) Because XEmacs does not have emacs-mule coding system, drafts > which are written under FSF Emacs are not readable with XEmacs. > > Therefore, we think that it is necessary to change the default value > of message-draft-coding-system from emacs-mule to a coding system > which is compatible between emacsen and can be used to encode > multilingual text safely, such as iso-2022-7bit. I agree that new files should be written using that encoding. It does not mean that message-draft-coding-system must the variable to do this. Maybe we could make that variable obsolete and use a new one. > Unfortunately, once the default value of message-draft-coding-system > is changed to iso-2022-7bit, old drafts encoded in emacs-mule will not > be decoded correctly. The trick described by Mr. Yamaoka is designed > to solve this problem. Right. It's a good trick, I think. Now I understand that we have been talking about different problems. That explains our misunderstandings :-) > Could you tell me how coding cookie solves this problem? The coding cookie does not deal with old files, only with new files. So the coding cookie is not a solution to the problem solved by Yamaoka-san. > It is true that we could safely change the default value of > message-draft-coding-system, if coding cookie was introduced. If it wasn't for the old files, we could... kai -- ~/.signature is: umop ap!sdn (Frank Nobis)