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: unibyte<->multibyte conversion [Re: Emacs-diffs Digest, Vol 2, Issue 28] Date: Tue, 21 Jan 2003 15:38:04 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301210638.PAA02983@etlken.m17n.org> References: 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 1043131973 3105 80.91.224.249 (21 Jan 2003 06:52:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 21 Jan 2003 06:52:53 +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 18asHE-0000nl-00 for ; Tue, 21 Jan 2003 07:52:52 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18asSS-00075I-00 for ; Tue, 21 Jan 2003 08:04:29 +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 18asCH-00012F-07 for emacs-devel@quimby.gnus.org; Tue, 21 Jan 2003 01:47:45 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18asAK-0000V8-00 for emacs-devel@gnu.org; Tue, 21 Jan 2003 01:45:44 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18as5W-0007cW-00 for emacs-devel@gnu.org; Tue, 21 Jan 2003 01:41:01 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18as3j-0006ok-00; Tue, 21 Jan 2003 01:38:55 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h0L6c5k06893; Tue, 21 Jan 2003 15:38:05 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h0L6c4R08769; Tue, 21 Jan 2003 15:38:04 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id PAA02983; Tue, 21 Jan 2003 15:38:04 +0900 (JST) Original-To: eliz@is.elta.co.il In-reply-to: (message from Eli Zaretskii on Tue, 21 Jan 2003 07:56:30 +0200 (IST)) 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) Original-cc: rms@gnu.org 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:10927 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10927 In article , Eli Zaretskii writes: > On Tue, 21 Jan 2003, Kenichi Handa wrote: >> > Sorry, I don't think I understand the difference. What will we have >> > in the buffer after process output is converted as you describe in the >> > last paragraph above? >> >> Ok, here's an example (Latin-1 lang. env.). > Thanks for taking time to explain these subtleties. >> (1) Reading a process output by raw-text into a multibyte >> buffer does AS conversion. I think this should do TO >> conversion to be consistent with (3). > I tend to agree, but without knowing the exact reason for the current > behavior, I fear that we will break something. I don't remeber well now. :-( Perhpas, because there was a choise only between string-as-multibyte and string-make-multibyte, and I thought string-as-multibyte is less surprising than string-make-multibyte. That is because the reason for specifying raw-text or no-conversion for process should be that one doesn't want code conversion. If we use string-make-multibyte, the result is almost the same as decoding by, for instance, iso-latin-1. If we had string-to-multibyte at that time, I might have used it. --- Ken'ichi HANDA handa@m17n.org