From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: utf-16le vs utf-16-le Date: Tue, 15 Apr 2008 06:25:47 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1208229975 15246 80.91.229.12 (15 Apr 2008 03:26:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Apr 2008 03:26:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 15 05:26:53 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 1Jlbop-0005Bb-Eg for ged-emacs-devel@m.gmane.org; Tue, 15 Apr 2008 05:26:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jlbo9-0007Zl-BL for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 23:26:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jlbo4-0007ZV-T4 for emacs-devel@gnu.org; Mon, 14 Apr 2008 23:26:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jlbnz-0007XO-Gv for emacs-devel@gnu.org; Mon, 14 Apr 2008 23:26:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jlbnz-0007XE-C1 for emacs-devel@gnu.org; Mon, 14 Apr 2008 23:25:59 -0400 Original-Received: from mtaout4.012.net.il ([84.95.2.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jlbny-0001X3-Kw for emacs-devel@gnu.org; Mon, 14 Apr 2008 23:25:59 -0400 Original-Received: from HOME-C4E4A596F7 ([83.130.246.94]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0JZC003ZMKUF72R8@i_mtaout4.012.net.il> for emacs-devel@gnu.org; Tue, 15 Apr 2008 06:39:56 +0300 (IDT) In-reply-to: <87fxtof8x1.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 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:95239 Archived-At: > From: "Stephen J. Turnbull" > Date: Tue, 15 Apr 2008 06:01:14 +0900 > Cc: emacs-devel@gnu.org > > Eli Zaretskii writes: > > > Which 9 are needed by UTF-8? I only see 4: the auto-detecting one, > > then one each for -unix. -dos, and -mac. What am I missing? > > BOM-{prohibited,auto,required}. But we don't have these in Emacs, do we? > > Don't forget that en/decoding is used on strings as well, not only on > > buffers. Buffer-local variables won't cut it, I think. > > Strings don't have encoding signatures or newline variants ??? Of course, they do. Emacs has no way of knowing what will be done with the encoded string; in particular, you might well insert it into a buffer or append it to a file. Are you saying that Emacs should, at the time of actual use of the string re-en/decode it according to usage? > 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? A string can be sent to a process, for example, so we must have some way of generating an external representation for it.