From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Schwab Newsgroups: gmane.emacs.devel Subject: Re: utf-16le vs utf-16-le Date: Mon, 14 Apr 2008 23:15:35 +0200 Message-ID: References: <87wsn1fl72.fsf@uwakimon.sk.tsukuba.ac.jp> <87prssgacl.fsf@uwakimon.sk.tsukuba.ac.jp> <851w58q24a.fsf@lola.goethe.zz> <87lk3gfg40.fsf@uwakimon.sk.tsukuba.ac.jp> <87fxtof8x1.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1208207911 15766 80.91.229.12 (14 Apr 2008 21:18:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Apr 2008 21:18:31 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 14 23:19:05 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JlW3x-0004u2-At for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 23:18:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlW3G-0005MH-OQ for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 17:17:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JlW3D-0005MA-Al for emacs-devel@gnu.org; Mon, 14 Apr 2008 17:17:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JlW38-0005Lf-9d for emacs-devel@gnu.org; Mon, 14 Apr 2008 17:17:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlW37-0005LW-V5 for emacs-devel@gnu.org; Mon, 14 Apr 2008 17:17:13 -0400 Original-Received: from mx2.suse.de ([195.135.220.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JlW2N-0002HR-Vh; Mon, 14 Apr 2008 17:16:30 -0400 Original-Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id F302B44C3C; Mon, 14 Apr 2008 23:15:35 +0200 (CEST) X-Yow: This is my WILLIAM BENDIX memorial CORNER where I worship William Bendix like a GOD!! In-Reply-To: <87fxtof8x1.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 15 Apr 2008 06:01:14 +0900") User-Agent: Gnus/5.110008 (No Gnus v0.8) Emacs/22.1 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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: news.gmane.org gmane.emacs.devel:95216 Archived-At: "Stephen J. Turnbull" writes: > Eli Zaretskii writes: > > > Don't forget that en/decoding is used on strings as well, not only o= n > > buffers. Buffer-local variables won't cut it, I think. > > Strings don't have encoding signatures or newline variants; those > octet sequences if present in a string are merely binary octet > sequences. They only have special semantics in external > representations. Where's the problem? The whole point of en/decoding is to convert between internal and external representation, no matter whether operating on a buffer or a string. Andreas. --=20 Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED= 5 "And now for something completely different."