From xemacs-m  Sun Feb 16 22:52:01 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
	by xemacs.org (8.8.5/8.8.5) with SMTP id WAA11932
	for <xemacs-beta@xemacs.org>; Sun, 16 Feb 1997 22:52:01 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA00918; Sun, 16 Feb 1997 20:51:30 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA00824; Sun, 16 Feb 1997 20:51:25 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA08271; Sun, 16 Feb 1997 20:51:26 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA18648; Sun, 16 Feb 1997 20:51:24 -0800
Date: Sun, 16 Feb 1997 20:51:24 -0800
Message-Id: <199702170451.UAA18648@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Kyle Jones <kyle_jones@wonderworks.com>
Cc: beta-list <xemacs-beta@xemacs.org>
Subject: Re: iso-2022
In-Reply-To: <QQcdbk18258.199702160010@crystal.WonderWorks.COM>
References: <Pine.SUN.3.95.970211233001.27642A-100000@bay1.bayserve.net>
	<9702120852.AA17900@lspsun16.epfl.ch>
	<199702130913.BAA05278@xemacs.eng.sun.com>
	<QQcdbk18258.199702160010@crystal.WonderWorks.COM>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Kyle" == Kyle Jones <kyle_jones@wonderworks.com> writes:

Kyle> 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).

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

Yes, I think 'no-conversion is correct, assuming folders will always
use the native EOL convention, and that the newline character is never
used as part of the encoding for some other character (a fairly safe
assumption.  The world will likely use UTF-8 to encode Unicode,
instead of the 2-byte format UCS-2.

Kyle> So, if I

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

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

This is the expected behavior.

One idea is that the various file operation functions such as
find-file will have an extra coding system argument so that you can do

(find-file "blah" no-conversion)

which should be equivalent to Kyle's code.

In either case, the EOL characteristics of the file will be
autodetected and preserved.  

Martin

