From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: decode-coding-string gone awry? Date: Tue, 15 Feb 2005 12:28:07 -0500 Message-ID: References: <874qgf1dkv.fsf-monnier+emacs@gnu.org> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1108490161 30966 80.91.229.6 (15 Feb 2005 17:56:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Feb 2005 17:56:01 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 15 18:55:54 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1D16vS-0005Hz-00 for ; Tue, 15 Feb 2005 18:55:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D17BF-0005N4-3m for ged-emacs-devel@m.gmane.org; Tue, 15 Feb 2005 13:12:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D1711-0001iD-0z for emacs-devel@gnu.org; Tue, 15 Feb 2005 13:01:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D1710-0001ht-CP for emacs-devel@gnu.org; Tue, 15 Feb 2005 13:01:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D16uN-0007qc-Rs for emacs-devel@gnu.org; Tue, 15 Feb 2005 12:54:47 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D16Yi-0001Hy-Ko for emacs-devel@gnu.org; Tue, 15 Feb 2005 12:32:24 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1D16UZ-00008W-Qk; Tue, 15 Feb 2005 12:28:07 -0500 Original-To: David Kastrup In-reply-to: (message from David Kastrup on Mon, 14 Feb 2005 18:24:55 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:33492 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33492 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.