Re: \201 irritation! :-)

[Dave Love <d.love@dl.ac.uk>]

>>>>> "FW" == Florian Weimer <fw@deneb.enyo.de> writes:

 FW> Byte-combination kills the quoted-printable encoder (or used to
 FW> do it in the past, at least).

I don't see why it should, at least for a sane charset.  Do you know
exactly how it fails?  I assume Mule 5 will solve such problems, but I
want to make sure.

 FW> Copying byte-combinations between unibyte and multibyte buffers
 FW> results in some weird effects.  Sometimes, Emacs is not 8-bit
 FW> clean. :-(

I don't know what that means.  Just spurious combination of leading
bytes stuffed raw into a multibyte buffer or something else?
(Obviously going multibyte->unibyte is generally lossy.)  `8-bit
clean' doesn't seem meaningful in a multibyte setting, but Emacs is so
if you operate purely in unibyte (modulo `set-input-mode', perhaps).

 >> Anyway, the `eight-bit-control' charset in Mule 5.0 should fix that
 >> sort of thing in the future, as well as allowing better auto-detection
 >> of utf-8.

 FW> Does "encode-coding-region" produce characters in this encoding?

Do you mean _de_code-coding-region?  `encode-coding-region' would
produce raw bytes.

(find-charset-string (decode-coding-string "\344b\205" 'latin-9))
  => (ascii latin-iso8859-15 eight-bit-control)

 FW> BTW: Please do not abuse GRAVE ACCENT (U+0060) as quotation mark.
 FW> Thanks.

It's too late for that, but this will be ASCII.