Re: guile can't find a chinese named file

[Chris Vine <chris@cvine.freeserve.co.uk>]

On Wed, 15 Feb 2017 12:48:20 +0100
<tomas@tuxteam.de> 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.

Chris