Re: guile can't find a chinese named file

[tomas]

-----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
> <address@hidden> 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-----