Re: encoding of etc/HELLO

Ar an dara lá de mí Iúil, scríobh Stephen J. Turnbull: Right, that doesn’t contradict what I said. ‘Unibyte coding system’ has no meaning in XEmacs. 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, XEmacs will not assign Cyrillic text read from UTF-8 files on disk to code points between #x80 and #x100, upcasing will leave ф as ф and will change Ц to ц, If a user opens an iso-2022-7 file with Japanese text in non-Mule and manipulates it as ASCII (say, M-x replace-string $B RET $A RET) , any Japanese characters will be trashed if their code points overlap. If a user types ƒ in non-Mule under X11, digit 2 appears in the buffer. If a user types „, | appears in the buffer. If a user types ф, some ASCII character appears. This is unusable for inputting those characters. Trashing the user’s non-Latin-1 data is the fundamental design decision of no-Mule. If someone cares about non-Latin-1 data, that person should be using Mule. And Mule is plenty fast enough these days, and I’ve put years of work into fixing bugs in it, it’s stable too. -- ‘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