From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Emacs-diffs Digest, Vol 2, Issue 28 Date: Mon, 27 Jan 2003 21:20:00 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301271220.VAA14902@etlken.m17n.org> References: <200301200152.KAA16258@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1043674718 4962 80.91.224.249 (27 Jan 2003 13:38:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 27 Jan 2003 13:38:38 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18d9T8-0001Hh-00 for ; Mon, 27 Jan 2003 14:38:34 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18d9XL-0004Jx-00 for ; Mon, 27 Jan 2003 14:42:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18d9J2-0003aQ-04 for emacs-devel@quimby.gnus.org; Mon, 27 Jan 2003 08:28:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18d8Gv-0002Il-00 for emacs-devel@gnu.org; Mon, 27 Jan 2003 07:21:53 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18d8G5-00025P-00 for emacs-devel@gnu.org; Mon, 27 Jan 2003 07:21:17 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18d8Fj-0001vh-00; Mon, 27 Jan 2003 07:20:39 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h0RCK2k16440; Mon, 27 Jan 2003 21:20:02 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h0RCK1R19499; Mon, 27 Jan 2003 21:20:01 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id VAA14902; Mon, 27 Jan 2003 21:20:00 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Tue, 21 Jan 2003 13:18:26 -0500) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11124 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11124 In article , Richard Stallman writes: > string-make-multibyte > string-as-multibyte > string-to-multibyte > These three are all useful. > string-make-unibyte > string-as-unibyte > string-to-unibyte (perpaps the same as string-as-unibyte, or > it should signal an error if non-ascii, > non-eight-bit-XXX is contained). > I don't see a need to add string-to-unibyte. We have string-as/make-multibyte and string-as/make-unibyte. If one finds string-to-multibyte, it's quite natural that he also expects string-to-unibyte. Even if it is an alias of string-as-unibyte, I think it's worth having it. And, it's simpler to have it than saying that we don't have string-to-unibyte because ... in some place. And I think it's better that it signals an error as written above. > buffer-make-multibyte > buffer-as-multibyte (same as (set-buffer-multibyte BUFFER t)) > buffer-to-multibyte > I don't think buffer-make-multibyte and buffer-to-multibyte are > useful. What is useful is to have functions to operate on a region in > a multibyte buffer, transforming the text between these three > different representations. (Some of the 6 transformations may be > meaningless or impossible; we should only support the meaningful > ones.) I don't agree with having such function. I think such a case is where we have to use decode/encode-coding-region. Eight-bit chars in a multibyte buffer actually represent raw-bytes. Then the operation of turing them to characters is "decoding", not transforming. --- Ken'ichi HANDA handa@m17n.org