On Wed, 15 Feb 2017 12:48:20 +0100 <[email protected]> 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
