From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Newsgroups: gmane.lisp.guile.user Subject: Re: guile can't find a chinese named file Date: Wed, 15 Feb 2017 13:41:24 +0100 Message-ID: <20170215124124.GB9630@tuxteam.de> References: <87y3xspcux.fsf@fencepost.gnu.org> <578885360.4452806.1487105647708@mail.yahoo.com> <87r330cwhj.fsf@elektro.pacujo.net> <191859705.4469709.1487109121157@mail.yahoo.com> <20170214221914.1483ddb1@bother.homenet> <20170215091832.GA28017@tuxteam.de> <20170215101533.32b183bb@bother.homenet> <20170215114820.GA5999@tuxteam.de> <20170215121309.55e4556f@bother.homenet> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1487162540 16721 195.159.176.226 (15 Feb 2017 12:42:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Feb 2017 12:42:20 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Feb 15 13:42:14 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 1cdyuG-0003E1-3t for guile-user@m.gmane.org; Wed, 15 Feb 2017 13:42:00 +0100 Original-Received: from localhost ([::1]:40240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdyuI-00087n-RN for guile-user@m.gmane.org; Wed, 15 Feb 2017 07:42:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdytn-00086L-Bl for guile-user@gnu.org; Wed, 15 Feb 2017 07:41:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdytk-0002mc-9T for guile-user@gnu.org; Wed, 15 Feb 2017 07:41:31 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]:55153 helo=tomasium.tuxteam.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cdytk-0002mG-3b for guile-user@gnu.org; Wed, 15 Feb 2017 07:41:28 -0500 Original-Received: from tomas by tomasium.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1cdytg-0002gD-MD for guile-user@gnu.org; Wed, 15 Feb 2017 13:41:24 +0100 In-Reply-To: <20170215121309.55e4556f@bother.homenet> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 5.199.139.25 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:13226 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Feb 15, 2017 at 12:13:09PM +0000, Chris Vine wrote: > On Wed, 15 Feb 2017 12:48:20 +0100 > wrote: > > On Wed, Feb 15, 2017 at 10:15:33AM +0000, Chris Vine wrote: > [snip] > > > I would prefer guile to make the filename encoding a fluid. It > > > wouldn't deal with files mounted with mixed encodings, but it would > > > cater for everything else. > > > > But why? I think either (a) have an internal encoding which is > > "mostly UTF-8", but has space for raw bytes, as David describes > > or (b) keeping completely out and dealing in arrays of bytes, > > and providing the filename encoding just as an advisory value > > ("as far as we can know, those file names are encoded FOO") > > seems far superior, since it will deal even with mixed encodings. > > I would be happy with that. But we have to work in the land of the > achievable. Making the filename encoding a fluid shouldn't be a major > exercise. Guile-2.0 already converts filenames from its internal string > representation (Latin-1 or UCS-4) to the locale encoding when opening up > files and the like in C; this would need instead to do the conversion > by reference to the fluid value (which could default to the locale > encoding). > > Option (a) you mention would seem to require rewriting the string > implementation. Option (b) may be more tractable (perhaps there could > be an option to pass file names using bytevectors) but someone has > still got to do it and I am not sure how that would work with windows. Of course it can only be done piecemeal. For (a), the first step would be to have a separate "omnivore string" representation (possibly as a smob) and the neccessary I/O operations. For (b), have the I/O operations to get the things (file names, environments) as raw byte arrays. This way, people could at least fight, when necessary. But true, I haven't even a clue how difficult that would be. What I don't like about the fluid is that it still doesn't give you an escape hatch in hard cases (your USB stick example). regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlikTHQACgkQBcgs9XrR2kbfjQCfTvSlVxYvPtZrLK9iUu7vfjSn /L8An3WuJW+NHZhA5sOJK2GwMJQ5bbSV =AZ7S -----END PGP SIGNATURE-----