From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: on eshell's encoding Date: Tue, 26 Jul 2016 21:35:27 +0300 Message-ID: <83shuws0wg.fsf@gnu.org> References: <86fuqw5vd8.fsf@toledo.com> <864m7c5oqc.fsf@toledo.com> <83twfcs4j1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1469558251 7445 80.91.229.3 (26 Jul 2016 18:37:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jul 2016 18:37:31 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jul 26 20:37:26 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bS7EK-0003QB-70 for geh-help-gnu-emacs@m.gmane.org; Tue, 26 Jul 2016 20:37:24 +0200 Original-Received: from localhost ([::1]:41732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bS7EJ-0001NY-FE for geh-help-gnu-emacs@m.gmane.org; Tue, 26 Jul 2016 14:37:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bS7Cy-0000rd-Dp for help-gnu-emacs@gnu.org; Tue, 26 Jul 2016 14:36:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bS7Cu-0008MQ-6A for help-gnu-emacs@gnu.org; Tue, 26 Jul 2016 14:35:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bS7Cu-0008MI-31 for help-gnu-emacs@gnu.org; Tue, 26 Jul 2016 14:35:56 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2562 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bS7Cq-00074S-2r for help-gnu-emacs@gnu.org; Tue, 26 Jul 2016 14:35:54 -0400 In-reply-to: (message from Yuri Khan on Wed, 27 Jul 2016 00:26:42 +0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:110943 Archived-At: > From: Yuri Khan > Date: Wed, 27 Jul 2016 00:26:42 +0600 > Cc: "help-gnu-emacs@gnu.org" > > On Wed, Jul 27, 2016 at 12:17 AM, Eli Zaretskii wrote: > > > The only way to break the limitations of the > > system codepage is to use the Unicode (a.k.a. "wide") APIs, which > > expect strings in UTF-16 encoding. But that is not currently > > supported in Emacs, due to boring technical problems. > > It’s not even clear if using the wide API on the caller side will > suffice. The callee also needs to cooperate, by using the > corresponding wide API to retrieve the command line arguments. Yes, and that's one of the few reasons why Emacs on Windows doesn't bother to use the wide APIs: too few programs Emacs users normally invoke can cooperate like that. But if Emacs did use the wide APIs, it wouldn't have been a loss, because programs that use ANSI APIs to access their command-line arguments would have them converted to the system codepage by Windows, and so it would have worked or not exactly as it does or doesn't now.