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

[Joachim Schrod]

>>>>> "SJT" == Stephen J Turnbull <stephen at xemacs.org> writes:
SJT> Joachim Schrod writes:

>> The culprit of that behaviour is the insertion of the following line
>> with the when clause into latin-unity.el.

SJT> Probably this is in fact uncovering a bug in the definition of ISO
SJT> 8859-1 used by latin-unity; I bet the problem is that there are 
SJT> C1 control characters in the file.  In proper ISO 8859-1 these cannot
SJT> be encoded, but in XEmacs's iso-8859-1 coding-system they can be.

Yes, there are C1 chars in this file.

But I still want to address that either I don't understand the
precondition under which latin-unity operates or that precondition
has a flaw.

This is a buffer where the buffer-file-coding-system has been
explicitly set to binary. 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. By definition, binary files consist only
of octets and should be written out as-is, without any attempt to
change any octets.

Actually, I can augment my problem description: VM may not be involved
at all. 

    If I open the file, set the buffer-file-coding-system explicitly
    to binary, modify it, and want to save it, latin-unity detects a
    coding system conflict. But it should not do so for binary files.

Therefore I would have thought that #'latin-unity-sanity-check checks
for the special case of binary files and returns that encoding as
save. (Or, maybe that at least binary is added to
'latin-unity-ucs-list, because one could classify it as an universal
encoding -- all octets in binary files represent themselves.)

Of course, it may well be that I have again misunderstood the approach
for coding systems, therefore I would appreciate an explanation.

Best,
	Joachim

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