Gnus development mailing list
 help / color / mirror / Atom feed
From: TSUCHIYA Masatoshi <tsuchiya@namazu.org>
Subject: Re: coding-system for drafts
Date: Sun, 03 Nov 2002 00:34:09 +0900	[thread overview]
Message-ID: <20021103003409A.1000@pine.kuee.kyoto-u.ac.jp> (raw)
In-Reply-To: <84y98htj5s.fsf@crybaby.uni-duisburg.de>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 2652 bytes --]

>> On Tue, 29 Oct 2002 15:27:11 +0100
>> kai.grossjohann@uni-duisburg.de (Kai Gro^[.A^[N_johann) said as follows:

>> 3. Under FSF Emacs, read a draft file as raw-text into a buffer
>>    if the value of message-draft-coding-system is iso-2022-7bit,
>>    otherwise use the value of message-draft-coding-system itself
>>    to read a file.  In the former case, decode the buffer
>>    contents as emacs-mule if there are over-7-bit data in a
>>    buffer, otherwise decode the contents using the value of
>>    message-draft-coding-system.

>Why can't you read a draft as iso-2022-7bit?

I think that his intention is to decode old drafts which were
genereted by old Gnusae safely.

>And then, you could write the encoding of the draft into a header.
>Then a missing header means to do what has been done up to now so we
>stay backwards compatible.

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.

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?

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.

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.  Could you tell me how coding cookie solves
this problem?

It is true that we could safely change the default value of
message-draft-coding-system, if coding cookie was introduced.

-- 
TSUCHIYA Masatoshi



  parent reply	other threads:[~2002-11-02 15:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-25 12:25 sending delayed articles bug Katsumi Yamaoka
2002-10-25 13:01 ` Kai Großjohann
2002-10-29  9:58   ` coding-system for drafts (was Re: sending delayed articles bug) Katsumi Yamaoka
2002-10-29 14:27     ` coding-system for drafts Kai Großjohann
2002-10-30  1:36       ` Katsumi Yamaoka
2002-10-30 10:15         ` Kai Großjohann
2002-10-30 12:28           ` Katsumi Yamaoka
2002-10-30 16:14             ` Kai Großjohann
2002-10-31  4:44               ` Katsumi Yamaoka
2002-10-31  7:35                 ` Katsumi Yamaoka
2002-10-31 17:35                   ` Kai Großjohann
2002-11-01  4:32                     ` Katsumi Yamaoka
2002-11-05 12:36                       ` Kai Großjohann
2002-10-31 17:30                 ` Kai Großjohann
2002-11-01 17:49                   ` Kai Großjohann
2002-11-05  9:23                     ` Katsumi Yamaoka
2002-11-05 12:38                       ` Kai Großjohann
2002-11-08  7:25                         ` Katsumi Yamaoka
2002-11-13 16:14                           ` Reiner Steib
2002-11-02 15:34       ` TSUCHIYA Masatoshi [this message]
2002-11-05 12:23         ` Kai Großjohann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021103003409A.1000@pine.kuee.kyoto-u.ac.jp \
    --to=tsuchiya@namazu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).