Richard Stallman <[EMAIL PROTECTED]> 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
