Re: decode-coding-string gone awry?

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Phooey.  Ok, this sounds like it makes sense.  It also sounds like it
should work also under XEmacs without having to engage my brain in
particular.

Now I am venturing into the realm of pure luxury: is there a way to
have the eight-bit-* chars display as octal escapes always even when
real latin1 characters (inserted by a process with process-coding
latin1) get displayed transparently?  I seem to remember that in those
"crazy" utf-8 buffers I had, those that were created by decoding
raw-text, there appeared latin-1 characters like the infamous Ã
character.  But maybe I am mistaken about that.  I'll just experiment
with the stuff a bit and probably use C-x = a lot.

Thanks,

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum