Re: \201 irritation! :-)

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

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

 FW> If there is a byte-combination, "(char-after)" returns values
 FW> outside the usual 0 .. 255 range, and
 FW> "quoted-printable-encode-region" doesn't handle this.

Then it's either intrinsically broken or not being used appropriately
since it doesn't make sense for multibyte characters.  I suppose I'll
have to check it if no-one else can.

 FW> The best thing probably is to switch the buffer to
 FW> uni-byte mode during quoted-printable encoding.

Whatever you do, you need a buffer with encoded contents.  Making it
unibyte isn't right otherwise or you're dealing with the emacs-mule
charset.

 >> I don't know what that means.  Just spurious combination of leading
 >> bytes stuffed raw into a multibyte buffer or something else?

 FW> Take the "Chinese" line from the HELLO file, copy it to a
 FW> multi-byte buffer, do "encode-coding-region" on it and specify
 FW> "utf-8" as encoding.  Copy the result to a unibyte buffer, and
 FW> paste it back into the first (multi-byte) buffer.  

This seems to be just confusing several issues.  I don't see how it's
related to spurious byte combination, unless it refers to some problem
in Mule-UCS itself.  Can you give a code snippet demonstrating the
problems you're concerned about without using utf-8 as an example?  It
shouldn't be relevant.  Be careful to include the relevant context
(C-h C, at least) since you're concerned with code conversion.

 FW> Now the \201s are there, you can see them if you switch the first
 FW> buffer to uni-byte mode.

Of course you see the internal encoding if you switch it to unibyte
mode anyway.  You may also have pasted in raw bytes.

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

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

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

So don't do that.  That's the point.

I'm not getting any indication that there is an issue here that needs
to be addressed in Emacs in future.