Ar an seachtú lá de mí Feabhra, scríobh Joachim Schrod: That’s what the FSF have. We (XEmacs) don’t distinguish iso-8859-1 and binary in your sense; they do. Neither version distinguishes ASCII and binary. But if the corresponding buffer contains characters that have no clear mapping to octets with the binary coding system, writing that buffer to disk will lose data. control-1 characters have a clear mapping to octets with the binary coding system. latin-unity not knowing about that mapping is the bug. In the correct course of events, VM will use MIME-encoding to generate a buffer where every character is a member of either ascii, control-1 or latin-iso8859-1, then write the buffer using 'binary. latin-unity will then look through the contents of the buffer, see that it can be encoded using 'binary, and all will be well. No, one could not. Consider; how can you interpret a sequence of octets on disk as U+5357, the Han character for ‘southwards,’ without abandoning the treatment as ‘binary’--a sequence of octets--and checking instead for ISO-2022-1 or UTF-8 sequences? If that character is in an XEmacs buffer, and that buffer is to be written using the binary coding system, how can you represent that character on disk without resorting to an alternative representation? All octets in binary files, when those files are read by XEmacs as binary, are represented by characters in the ascii, control-1 or latin-iso8859-1 character sets. This was a choice we made--an alternative would have been a combination of latin-jisx0201, control-1 and latin-iso8859-2. There are better reasons for the first choice, but it was still a choice. -- On the quay of the little Black Sea port, where the rescued pair came once more into contact with civilization, Dobrinton was bitten by a dog which was assumed to be mad, though it may only have been indiscriminating. (Saki) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta