Re: decode-coding-string gone awry?

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     Yuk.  The problem is that this buffer is not only processed by
>     preview-latex, but also by AUCTeX, and the versions that get combined
>     may be different.  AUCTeX uses the source code buffer's file encoding
>     by default, which is fine for basically unibyte based coding systems.
>
> It sounds like the safest thing is to convert the string to what you
> want, just before you use it.
>
>     If decode-coding-string is supposed to have a chance of reassembling
>     this junk, it must only be run at the end of reconstructing the byte
>     stream.  Yes, this is completely insane.  No, I can't avoid having to
>     deal with it somehow.
>
> If you reconstruct the correct byte stream, it should work to apply
> decode-coding-string to it.

Yes, it now works.  The process has a process-encoding of raw-text,
inserts in the (multibyte) error message buffer.  The buffer contents
(which are error messages with error contexts) are then tried to be
matched with the source buffer from the compilation directly.  If this
fails, the error message buffer contents are taken,
(encode-coding-string 'raw-text)ed again, the ^^xx hexadecimal bytes
are converted to their equivalent bytes, and then the stuff gets
(decode-coding-string 'buffer-coding-system)ed with the encoding of
the source buffer with which those error messages are compared.  At
this time the error contexts should really match (or I'll start
weeping).

It currently appears to work with all sane and insane combination of
TeX quoting schemes, system language environments and Emacs language
settings.

Thanks for all the help here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum