[Bug: 21.5-b25] Problems with latin-unity and VM

[Joachim Schrod]

>>>>> "AK" == Aidan Kehoe <kehoea at parhasard.net> writes:
AK>  Ar an seachtú lá de mí Feabhra, scríobh Joachim Schrod: 

>> I would have expected that latin-unity does NOT attempt to change
>> the encoding at all for such files -- after all, they are declared
>> as binary and the notion of Latin characters in binary files makes
>> no sense.

AK> We (XEmacs) don’t distinguish iso-8859-1 and binary in your sense;

Ah -- that I didn't know. Reading the Coding System section of the
XEmacs manual, it didn't seem so, there differences between binary and
iso-8859-1 are explicitly named.

    In contrast, the coding system `binary' specifies no character
    code conversion at all--none for non-Latin-1 byte values and none
    for end of line. This is useful for reading or writing binary
    files, tar files, and other files that must be examined verbatim.

But with that information your explanation gets clearer. Though I have
to say that I would have naively answered your question

AK> Consider; how can you interpret a sequence of octets on disk as
AK> U+5357, the Han character for ‘southwards,’ without abandoning the
AK> treatment as ‘binary’--a sequence of octets--and checking instead
AK> for ISO-2022-1 or UTF-8 sequences?

as follows: In buffers with coding system 'binary there must not be
the character U+5357, by definition, because no such octet exists. 
When the buffer-file-coding-system-for-read is set to 'binary, such a
character would not be constructed at all. Yanking that character in
such a buffer would signal an error. I also would have expected any
attempt to set buffer-file-coding-system to 'binary in a buffer with
such a character to signal an error.

But I start to understand your design, too.

Thanks your your information,

	Joachim

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod				Email: jschrod at acm.org
Roedermark, Germany