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: setenv -> locale-coding-system cannot handle ASCII?! Date: Wed, 26 Feb 2003 09:58:23 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200302260058.JAA28973@etlken.m17n.org> References: <200302250634.PAA27478@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 1046221165 16108 80.91.224.249 (26 Feb 2003 00:59:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2003 00:59:25 +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 18npuu-0004Bf-00 for ; Wed, 26 Feb 2003 01:59:24 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18nqB5-0000MU-00 for ; Wed, 26 Feb 2003 02:16:07 +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 18npul-0004eX-01 for emacs-devel@quimby.gnus.org; Tue, 25 Feb 2003 19:59:15 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18npuH-0004NE-00 for emacs-devel@gnu.org; Tue, 25 Feb 2003 19:58:45 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18npuC-0004Hv-00 for emacs-devel@gnu.org; Tue, 25 Feb 2003 19:58:40 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nptz-0003lS-00; Tue, 25 Feb 2003 19:58:28 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h1Q0wOk12636; Wed, 26 Feb 2003 09:58:24 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h1Q0wNR05538; Wed, 26 Feb 2003 09:58:23 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id JAA28973; Wed, 26 Feb 2003 09:58:23 +0900 (JST) Original-To: miles@gnu.org In-reply-to: (message from Miles Bader on 25 Feb 2003 15:47:37 +0900) 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: d.love@dl.ac.uk Original-cc: sds@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:11954 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11954 In article , Miles Bader writes: > Kenichi Handa writes: >> > [I'm confused about what `multibyte-string-p' actually _means_, by the >> > way -- shouldn't it only ever return t if the string contains non-ascii >> > characters?] >> >> Looong ago I proposed the same thing to Richard. His answer >> was that the multibyteness of a string should follow the >> source of the string. > That would seem to make it almost useless for a lisp programmer... > What is the purpose of using it in a function like `setenv'? > Is it just an efficiency hack? If so, why not just move the test into > find-coding-systems-string [or whatever function actually does the work > for it] so that ordinary programms don't have to worry about such > sillyness? For this part: (if (and (multibyte-string-p variable) locale-coding-system) (let ((codings (find-coding-systems-string (concat variable value)))) (unless (or (eq 'undecided (car codings)) (memq (coding-system-base locale-coding-system) codings)) (error "Can't encode `%s=%s' with `locale-coding-system'" variable (or value ""))))) yes, multibyte-string-p is just for efficiency. We can make it simply to: (let ((codings (find-coding-systems-string (concat variable value)))) (unless (or (eq 'undecided (car codings)) (memq (coding-system-base locale-coding-system) codings)) (error "Can't encode `%s=%s' with `locale-coding-system'" variable (or value "")))) But, in this part, (if (multibyte-string-p variable) (setq variable (encode-coding-string variable locale-coding-system))) multibyte-string-p is mandatory because encode-coding-string will change the byte-sequence of `variable' even if it is unibyte. Ex. (encode-coding-string "\201\300" 'iso-latin-1) => "\300" By the way, I still think it's better to have multibyte strings in process-environment in a multibyte session. But, it seems that Richard is not convinced. So, we need something like this Dave's change. --- Ken'ichi HANDA handa@m17n.org