From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.lisp.guile.user Subject: Re: guile can't find a chinese named file Date: Mon, 30 Jan 2017 21:32:41 +0200 Message-ID: <83sho0wdgm.fsf@gnu.org> References: <874m0gd3z4.fsf@gnu.org> <87wpdc8rx7.fsf@elektro.pacujo.net> <87poj4r04c.fsf@fencepost.gnu.org> <87k29c8q3b.fsf@elektro.pacujo.net> <87h94gqz34.fsf@fencepost.gnu.org> <87fuk0ctve.fsf@elektro.pacujo.net> <878tpsqtzl.fsf@fencepost.gnu.org> <83tw8gwffh.fsf@gnu.org> <8737g0qsp8.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485804808 27655 195.159.176.226 (30 Jan 2017 19:33:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2017 19:33:28 +0000 (UTC) Cc: guile-user@gnu.org To: David Kastrup Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 30 20:33:22 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYHhY-0006pb-EW for guile-user@m.gmane.org; Mon, 30 Jan 2017 20:33:20 +0100 Original-Received: from localhost ([::1]:34730 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYHhc-0002il-9Z for guile-user@m.gmane.org; Mon, 30 Jan 2017 14:33:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYHhE-0002iZ-Jo for guile-user@gnu.org; Mon, 30 Jan 2017 14:33:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYHh9-0001jE-TH for guile-user@gnu.org; Mon, 30 Jan 2017 14:33:00 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYHh9-0001j8-Pq; Mon, 30 Jan 2017 14:32:55 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4250 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cYHh8-0003bf-Ei; Mon, 30 Jan 2017 14:32:55 -0500 In-reply-to: <8737g0qsp8.fsf@fencepost.gnu.org> (message from David Kastrup on Mon, 30 Jan 2017 20:00:03 +0100) 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: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13150 Archived-At: > From: David Kastrup > Cc: marko@pacujo.net, guile-user@gnu.org > Date: Mon, 30 Jan 2017 20:00:03 +0100 > > Eli Zaretskii writes: > > > One other crucial detail is that Emacs also has unibyte strings > > (arrays of bytes), which are necessary during startup, when Emacs > > doesn't yet know how to decode non-ASCII strings. Without that, you > > wouldn't be able to start Emacs in a directory whose name includes > > non-ASCII characters, because it couldn't access files it needs to > > read to set up some of its decoding machinery. > > Hm, I know that XEmacs-Mule emphatically does not have unibyte strings > (and Stephen considers them a complication and abomination that should > never have been left in Emacs), so it must be possible to get away > without them. I doubt that's possible, at least not in general. (You could get away if you assumed UTF-8 encoded file names.) Some translation tables for some encodings must load files using the likes of load-path, and if that includes non-ASCII file names, you are screwed unless you can use unibyte strings. That is why all Emacs primitives that accept file names support both unibyte and multibyte strings as file names. > And I don't think that the comparatively worse Mule implementation > of XEmacs is due to that decision. Emacs 20 vintage Mule didn't have all the sophisticated Unicode support machinery we have today, so maybe for that subset the above wasn't necessary. Then again, Emacs couldn't be safely built or started in a non-ASCII directory until just a few years ago, so perhaps no one bothered to test that thoroughly with XEmacs, except in ISO 2022 locales.