[info-mcl] Text files in MCL 5.2

[p2.edoc at googlemail.com]

At 5:47 PM -0400 08/06/05, Octav Popescu wrote:
>MCL 5.2 seems to have a problem with text files. It assumes the input
>file is encoded in MacRoman and converts it to Unicode strings on
>reading, but it doesn't do a reverse conversion on writing. And then it
>just writes the lower bytes of the unicode codes.

In the MCL 5.2 save file dialog is a new Format option for external-format
[MCL 5.1 Format]
[Unicode (UTF8)]
[Unicode (UTF16)]
[Unix line endings]

If a file is saved in [MCL 5.1 Format] or [Unix 
line endings] by 5.2 is should be read as 
original under MCL pre 5.2.

MCL 5.2 file saved as [Unicode (UTF8)],  under 
5.1 we see the BOM (Ôªø) file prefix.
         ditto         [Unicode (UTF16)], under 5.1 it cannot be read

the external file's format is found using 
utf-something-p (which assumes nothing, rather 
investigates the file contents and 
FSCataloginfo.FinderInfo.filetype).

for internal state, file-external-format looks 
for (view-get window :external-format).

if we save as [MCL 5.1 Format] ccl::view-alist has :EXTERNAL-FORMAT nil.

If I make and save a new file in pre-5.2 MCL,
then read in 5.2, utf-something-p file returns nil

the way the external-format argument is handled 
is of necessity a bit convoluted, see:

window-save-file
buffer-write-file
%buffer-write-file
choose-new-file-dialog
window-save-1
*save-as-original-format*
set-file-external-format
window-make-parts
ed-yank-file
etc.

but I can't see anything wrong, nor repeat the 
problem, nor find anything contrary to the 
unicode section of @Release Notes 5.2,
Can anyone give a repeatable instance of the problem (that we can reproduce)?
Is it the same is using Save, Save As..., Save Copy As... ?

I query why choose-new-file-dialog doesn't offer 
an external-format argument option, or see how to 
hide MCL-ness (aka [MCL 5.1 Format]) from end 
users (I'd prefer to be able to name that 
something like MacRoman or better "URF-8 no BOM" 
(see BBEdit for more Unicode embracing options)).

On the face of it, this bug (if it exists!) seems 
quite dire for people migrating their code from 
pre 5.2 to 5.2, so needs fixing such that all 
have complete confidence.

My wildest hunch is to explore the consequences 
of fonts in files (I don't use them).