From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Herbert Euler" Newsgroups: gmane.emacs.devel Subject: Re: Fcall_process: wrong conversion Date: Thu, 18 May 2006 14:07:04 +0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-Trace: sea.gmane.org 1147932461 10935 80.91.229.2 (18 May 2006 06:07:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 May 2006 06:07:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 18 08:07:38 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FgbfU-0006Hc-5q for ged-emacs-devel@m.gmane.org; Thu, 18 May 2006 08:07:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FgbfT-0003P7-MG for ged-emacs-devel@m.gmane.org; Thu, 18 May 2006 02:07:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FgbfF-0003O2-PJ for emacs-devel@gnu.org; Thu, 18 May 2006 02:07:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FgbfB-0003Ni-RJ for emacs-devel@gnu.org; Thu, 18 May 2006 02:07:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FgbfB-0003NW-Kv for emacs-devel@gnu.org; Thu, 18 May 2006 02:07:09 -0400 Original-Received: from [64.4.26.43] (helo=hotmail.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FgbiD-00022f-7j for emacs-devel@gnu.org; Thu, 18 May 2006 02:10:17 -0400 Original-Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 May 2006 23:07:07 -0700 Original-Received: from 64.4.26.200 by by112fd.bay112.hotmail.msn.com with HTTP; Thu, 18 May 2006 06:07:04 GMT X-Originating-IP: [216.145.54.158] X-Originating-Email: [herberteuler@hotmail.com] X-Sender: herberteuler@hotmail.com In-Reply-To: Original-To: handa@m17n.org X-OriginalArrivalTime: 18 May 2006 06:07:07.0967 (UTC) FILETIME=[4B3204F0:01C67A41] 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:54688 Archived-At: >From: Kenichi Handa >To: "Herbert Euler" >CC: emacs-devel@gnu.org >Subject: Re: Fcall_process: wrong conversion >Date: Thu, 18 May 2006 11:24:55 +0900 > > > For unifying character encodings? > >I don't understand the meaning of "unifying character >encodings". I meant to make encoding for arguments and file the same. > > I.e. if the file is in japanese-shift-jis, but command argument is in > > chinese-gbk, encoding arguments will make sure all characters are in > > japanese-shift-jis, won't it? > >I don't understand what "if ..." part actually means. Who >makes command argument in chinese-gbk? For example, I wrote a lisp command which uses `call-process' and contains characters in chinese-gbk as arguments. I meant, when I apply this command to a japanese-shift-jis file, `call-process' will encode the chinese-gbk characters to japanese-shift-jis in background, won't it? > > As you stated, there is no locale uses utf-16, so if utf-16 characters > > appear as command arguments, we can't expect most programs will have > > correct behaviors or at least the same behaviors as no utf-16 > > characters appear as command arguments, even if the commands are > > invoked within, for instance, shell scripts. > > > So perhaps we should only prevent encoding arguments for utf-16? > >It seems to be a good workaround for the hexl-mode because >it won't break anything. So, I installed a proper change >for that. > >Though, it doesn't solve the generic problem of "how to >handle the case that the program requests different encoding >for arguments and file (or stdin)". I think we should solve >it after the release. In my opinion, most programs seem not to require different encoding for arguments and file. Think about a program requires Japanese relative encoding as file encoding and Chinese relative encoding as argument encoding. If I provide simplified Chinese characters, which are not in the specific Japanese encoding, in command arguments, this program seems hardly taking a acceptable behavior, even if I execute the program by typing it in Shell. Namely, cross-encoding would make sense only if all the different encodings contain all characters involved and represent them the same way in an execution. In other conditions, users can't expect acceptable result. This unique condition is likely what already exists in the current code, except converting to utf-16. Regards, Guanpeng Xu _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/