From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: decode-coding-string gone awry? Date: Mon, 14 Feb 2005 22:07:58 +0100 Message-ID: References: <874qgf1dkv.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1108415393 25142 80.91.229.2 (14 Feb 2005 21:09:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 14 Feb 2005 21:09:53 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 14 22:09:53 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D0nTU-0007dH-Do for ged-emacs-devel@m.gmane.org; Mon, 14 Feb 2005 22:09:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D0nj6-0002Y2-1r for ged-emacs-devel@m.gmane.org; Mon, 14 Feb 2005 16:25:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D0nhO-00020N-QN for emacs-devel@gnu.org; Mon, 14 Feb 2005 16:24:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D0nhN-0001zg-Bi for emacs-devel@gnu.org; Mon, 14 Feb 2005 16:24:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D0nhN-0001zc-7V for emacs-devel@gnu.org; Mon, 14 Feb 2005 16:24:05 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D0nRm-0003sl-NK for emacs-devel@gnu.org; Mon, 14 Feb 2005 16:07:58 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D0nNk-0001tq-1D; Mon, 14 Feb 2005 16:03:48 -0500 Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Mon, 14 Feb 2005 15:56:17 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33427 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33427 Stefan Monnier 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 =C3 character. But maybe I am mistaken about that. I'll just experiment with the stuff a bit and probably use C-x =3D a lot. Thanks, --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum