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: Emacs-diffs Digest, Vol 2, Issue 28 Date: Tue, 21 Jan 2003 13:18:26 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200301200152.KAA16258@etlken.m17n.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1043173986 20464 80.91.224.249 (21 Jan 2003 18:33:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 21 Jan 2003 18:33:06 +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 18b3Bu-0005Dh-00 for ; Tue, 21 Jan 2003 19:32:06 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18b3NM-0005aY-00 for ; Tue, 21 Jan 2003 19:43:57 +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 18b33l-0000eJ-02 for emacs-devel@quimby.gnus.org; Tue, 21 Jan 2003 13:23:41 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18b32D-00006C-00 for emacs-devel@gnu.org; Tue, 21 Jan 2003 13:22:05 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18b31T-0008Ej-00 for emacs-devel@gnu.org; Tue, 21 Jan 2003 13:21:20 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18b2yg-0007Re-00 for emacs-devel@gnu.org; Tue, 21 Jan 2003 13:18:26 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 18b2yg-0007yl-00; Tue, 21 Jan 2003 13:18:26 -0500 Original-To: Kenichi Handa In-reply-to: <200301200152.KAA16258@etlken.m17n.org> (message from Kenichi Handa on Mon, 20 Jan 2003 10:52:31 +0900 (JST)) 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:10943 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10943 If we want a multibyte sequence but each character contained is one of ascii, eight-bit-control, and eight-bit-graphic corresponding to the original bytes, we must read by no-conversion, and insert characters one by one as below: (apply 'insert (string-to-list UNIBYTE-STRING)) Perhaps, we must have a function, say, string-to-multibyte, and make this enable. (insert (string-to-multibyte UNIBYTE-STRING)) I think we do need this function string-to-multibyte, and its doc string should carefully explain how it differs from string-make-multibyte. I don't remember why the current code does as above. I think the behaviour what Eli wrote is more consistent with the behaviour of file reading. Shall I change the code as what Eli wrote (by introducing the new function string-to-multibyte)? Please do introduce string-to-multibyte. What other change do you propose? I am not sure how what Eli wrote differs from the current behavior. By the way, it may be clean to have all these functions in parallel, and spare one section describing the difference of MAKE, AS, TO conversions in info. 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. 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.) buffer-make-unibyte buffer-as-unibyte (same as (set-buffer-multibyte BUFFER nil)) buffer-to-nuibyte I don't think any change here is worth making.