[EMAIL PROTECTED] (Ludovic Courtès) writes: > > My understanding is that, implicitly, Guile currently uses the current > locale's encoding as its "internal representation".
Not really, I believe it's a case of encoding ignorance, or at best agnosticism :-). A few functions care, but on the whole there's nothing uniformly applied. No doubt this is set to change, but for now you can have different strings with different encodings (as I've had the misfortune to be doing lately). If there were a single encoding enforced for strings then you'd for instance like existing strings converted upon doing a setlocale. All changing in the perhaps near future, until then I'd suggest doing as little as possible. (Make sure it's 8-bit clean and leave it at that.) > Are there many systems that provide `localeconv' but not `nl_langinfo'? > I guess Windows has the former but not the latter, in which case it > might make sense to support it. Supposedly there's a GetLocaleInfo or something on DOS, if anyone cared. > The issue is that (i) it is glibc-specific and (ii) it is not a desired > behavior in many cases. Yes, //translit is glibc, but putting question marks for bad chars is possible everywhere, and would be a nice feature, eventually. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
