Ar an triú lá de mí Iúil, scríobh Stephen J. Turnbull:
Aidan Kehoe writes:
> "Unibyte coding system" has no meaning in XEmacs.
Of course it does.
No. “Unibyte” is an FSF term. I can guess what you meant by it, but not
everyone puts the amount of time you do into reading the FSF lists, it’s not
immediately clear in the absence of that time.
> If a user is editing KOI8-R under non-Mule and has set a
buffer’s font
> to use a KOI8-R font, XEmacs corrupts data when Cyrillic is pasted in
> from another app,
I assume the other app is not using KOI8 then.
What? If the other app is using KOI8, it’ll transfer the selection using
either the UTF8_STRING or the COMPOUND_TEXT selection type, which will give
mojibake in XEmacs.
That's a PEBKAC. If users want to work in a multi-encoding
environment
(which these days means "pretty much any interprocess communication"),
they need to use Mule.
If the user wants non-Latin-1 data not to be trashed, they need to be using
Mule.
> XEmacs will not assign Cyrillic text read from UTF-8 files on
> disk to code points between #x80 and #x100, upcasing will leave
And your point might be? In no-Mule XEmacs, Latin-1 is text and text
modes will DTRT, other encodings are binary and require the same care
as when editing a tar file or DOS .exe by hand.
That’s the first time I’ve seen that opinion.
My point is simply that "C-u C-x C-f binary.file RET utf-8 RET
C-x C-w
copy.file RET" should either error or produce a byte-for-byte
identical copy in any version of XEmacs. You can classify the current
behavior as "wont fix", I'm not asking you to fix it. It is, however,
a bug, and a bad one.
Well, I’ve modified the issue tracker entry to reflect what I think of the
issue. You’re free to change that.
> character appears. This is unusable for inputting those
characters.
Sure, and there's no keyboard interface for producing tar file
metadata if you edit a tar file. That doesn't mean XEmacs should
corrupt the file just by reading it into a buffer and writing it back
out again!
> Trashing the user’s non-Latin-1 data is the fundamental design
> decision of no-Mule.
No. The fundamental design decision of no-Mule is that data is binary,
and mixing data of different types is the user's responsibility.
No. Were that the case, different line-endings wouldn’t be transformed to
Unix, and the various packages that allow transparent access to compressed
and encrypted data would give up.
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta