Re: Fcall_process: wrong conversion

[Herbert Euler]

> From: Kenichi Handa <address@hidden>
> To: "Herbert Euler" <address@hidden>
> CC: address@hidden
> 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/