Re: [Unicode-2] `read' always returns multibyte symbol

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> Kenichi Handa <handa@ni.aist.go.jp> wrote:

> In article <b4moddv20sy.fsf@jpl.org>,
>	Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> What I observed was different.

> That is exactly what string-as-multibyte does. \206\343 and
> \202\271 are valid multibyte forms in the current Emacs,
> thus are treated as multibyte characters.

I understood why such readable characters appeared abruptly.

[...]

> Please try this:

> (string-make-unibyte
>  (string-as-multibyte "\343\203\206\343\202\271\343\203\210"))

> You'll get the above result, ... yes, very weird.

Oh, it made me surprised a bit.  But I often view such a scene
while playing with unibyte and multibyte things, and it always
confuses me.

> On the other hand,

> (string-as-unibyte
>  (string-as-multibyte "\343\203\206\343\202\271\343\203\210"))
>  =>  "\343\203\206\343\202\271\343\203\210"

>>> I long ago proposed a facility that turns on the
>>> multibyteness of a buffer while converting 8-bit bytes to
>>> multibyte characters as what string-to-multibyte does, but
>>> not accepted.

>> But the modern Emacsen does do so, doesn't it?

> No.

Oops.  I misunderstood that the reason why Emacs 22 and 23 don't
break 8-bit data while they are being fed into a multibyte buffer
from a network process of which the process coding system is
binary.  So, maybe the best ways for the present are still to
use a unibyte buffer for unibyte data and to use a multibyte
buffer for multibyte data.  And use a string, not a buffer, to
encode and decode data if the multibyteness of data will change,
like:

(insert (prog1
	    (decode-coding-string (buffer-string) 'coding)
	  (erase-buffer)
	  (set-buffer-multibyte t)))