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

[Joachim Schrod]

>>>>> "AK" == Aidan Kehoe <kehoea at parhasard.net> writes:
>> 
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.

AK> I’m not aware of any environment that implements that
AK> behaviour--though it would seem more correct. Are you? Non-Unicode
AK> Windows apps, for example, trash data when people type in or paste
AK> characters that don’t occur in the app’s code page.

I have to admit that I'm neither aware of any editing program with
such a behaviour -- but I always wanted it, since programs more than
once trashed my data, just as you wrote. Blame my comments on my
wishful thinking. :-) :-)

But actually, since you ask: In the environment where I develop myself
(LaTeX core and associated programs like xindy, a multi-lingual index
processor), we throw errors when the user tries to process characters
that are invalid for an encoding. That was not always so; there was a
time when we simply ignored such characters, thus trashing the user's
documents, too. We are aware that TeX's error messages are something
that is often not readable for many persons; but at least we issue
them now.

Best,
	Joachim

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