Re: \201 irritation! :-)

[Florian Weimer <fw@deneb.enyo.de>]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "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?

If there is a byte-combination, "(char-after)" returns values outside
the usual 0 .. 255 range, and "quoted-printable-encode-region" doesn't
handle this.  The best thing probably is to switch the buffer to
uni-byte mode during quoted-printable encoding.  Perhaps adding
"mm-with-unibyte-current-buffer" could do the trick?

>  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?

Take the "Chinese" line from the HELLO file, copy it to a multi-byte
buffer, do "encode-coding-region" on it and specify "utf-8" as
encoding.  Copy the result to a unibyte buffer, and paste it back into
the first (multi-byte) buffer.  Now the \201s are there, you can see
them if you switch the first buffer to uni-byte mode.

The trouble with UTF-8 is that it tends to generate more
byte-combinations than other encodings, as it seems.

>  >> 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.

And these raw bytes are not properly dealt with in multi-byte buffers.