In article <address@hidden>, Richard Stallman <address@hidden> writes:
> ! The string argument is normally a multibyte string, except:
> ! - if the process' input coding system is no-conversion or raw-text,
> ! it is a unibyte string (the non-converted input), or else
> Is this really the right way for it to work?
> Should the choice of unibyte or multibyte string
> be tied in this way to the choice of coding system?
This facility was added upon someone's request or to fix
some problem long ago.
1998-12-21 Kenichi Handa <address@hidden>
[...]
* process.c (read_process_output): Decide the multibyteness of
string given to a process filter by a coding system used for
decoding the process output.
But, I don't remeber the detail now.
> If you want multibyte strings "without decoding", would emacs-mule
> give you that?
It depends on what kind of multibyte string we want.
If we want the same result as reading a file containing the
same byte sequence by emacs-mule, emacs-mule is fine. This
is the same as reading by no-converson, and insert the given
unibyte string by:
(insert (string-as-multibyte UNIBYTE-STRING)).
If we want a multibyte sequence that is the same as the
result of converting each of the original bytes by
unibyte-char-to-multibyte, we must read by no-conversion,
and insert the given unibyte string just by `insert':
(insert UNIBYTE-STRING)
This is the same as doing:
(insert (string-make-multibyte UNIBYTE-STRING))
If we want a multibyte sequence but each character contained
is one of ascii, eight-bit-control, and eight-bit-graphic
corresponding to the original bytes, we must read by
no-conversion, and insert characters one by one as below:
(apply 'insert (string-to-list UNIBYTE-STRING))
Perhaps, we must have a function, say, string-to-multibyte,
and make this enable.
(insert (string-to-multibyte UNIBYTE-STRING))
---
Ken'ichi HANDA
address@hidden