Re: decode-coding-string gone awry?

[Stefan Monnier]

> So that is basically the background why we can easily make the process
> raw-text, but quite less easily make the buffer unibyte: AUCTeX will
> use the same buffer for its next run, just erasing it, and if it has
> turned unibyte, we get into trouble.

OK.  raw-text is good.

> The process output coding system being raw-text.  Do I really need to
> actually encode raw-text?

If the string comes straight from raw-text (via a multibyte buffer), that
means it only has ascii and eight-bit-* chars, so all you need is to turn it
from multibyte to unibyte, which can be done with (encode-coding-string foo
'raw-text-unix) or (string-make-unibyte foo) or (string-as-unibyte foo).
The three options are basically equivalent in this case.

string-as-unibyte is +/- (encode-coding-string foo 'emacs-mule-unix)
string-make-unibyte is +/- (encode-coding-string foo locale-coding-system)

I personally prefer the use of encode-coding-string because it makes things
more explicit: you can mention that you're encoding with `raw-text' because
you're undoing the raw-text decoding done by the process's coding-system.
That makes it more obviously correct.


        Stefan