From xemacs-m  Sat Feb 15 18:10:01 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 SAA11428
	for <xemacs-beta@xemacs.org>; Sat, 15 Feb 1997 18:09:59 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcdbk18258; Sat, 15 Feb 1997 19:10:00 -0500 (EST)
Date: Sat, 15 Feb 1997 19:10:00 -0500 (EST)
Message-Id: <QQcdbk18258.199702160010@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: beta-list <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:
 > 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).

I'm thinking that no-conversion should be used so that CRLF -> LF
conversion occurs in Wintel-land and CR -> LF conversion occurs
in Macintosh land.  Otherwise VM is going to flipout trying to
parse folders using the wrong newline convention.

So, if I

(let ((overriding-file-coding-system 'no-conversion))
  (find-file "blah"))

will the proper newline conversion happen?  Also after the
find-file, will file-coding-system be set to correct version of
no-conversion so that write-region does the correct conversion
back to the local newline convention?

