From xemacs-m  Sat Feb 15 17:09:51 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id RAA10132
	for <xemacs-beta@xemacs.org>; Sat, 15 Feb 1997 17:09:50 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcdbg17322; Sat, 15 Feb 1997 18:09:51 -0500 (EST)
Date: Sat, 15 Feb 1997 18:09:51 -0500 (EST)
Message-Id: <QQcdbg17322.199702152309@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: Egome Fass <xemacs-beta@xemacs.org>
Subject: Re: iso-2022
In-Reply-To: <199702130913.BAA05278@xemacs.eng.sun.com>
References: <Pine.SUN.3.95.970211233001.27642A-100000@bay1.bayserve.net>
	<9702120852.AA17900@lspsun16.epfl.ch>
	<199702130913.BAA05278@xemacs.eng.sun.com>

Martin Buchholz writes:
 > You can get Japanese characters to appear in VM + tm-vm 7 when you
 > have done (set-language-environment) appropriately, but this is really
 > just an accident - two wrongs appearing to be a right.
 > 
 > When the message is initially read in (crashbox) the message is
 > converted.  This is wrong.  The message should be read in and stored
 > in raw mode (binary or no-conversion).  When the message is displayed
 > in the *Preview-inbox* buffer, tm-vm should be doing MIME conversion
 > based on MIME headers, or if those are not present, the current
 > language environment.  Because 2 things are done wrong, they `cancel'
 > and the user appears to get the characters correctly.  But the damage
 > becomes more obvious after VM is exited, the folder is saved, and VM
 > is started again - then the mail message is likely to be corrupted.

I'm in the process of going through VM and setting the coding
system in all the places where it needs to be set.  I needed to
do this for the DOS/NT FSF Emacs port anyway, since it has the
LF -> CRLF conversion issues.  (Wheeee.)

