Re: Accessing the environment's locale encoding settings

Hi, Apologies for not answering earlier, and for making changes without continuing this discussion. So here’s an after-the-fact reply. Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: >> It’s not completely satisfying either because --locale is not in >> 2.0.[0-3], so users who

Re: Accessing the environment's locale encoding settings

Hi, Since adding an implicit setlocale(LC_ALL, "") cannot be done in Guile 2.0 (it would change the default port encoding as a side effect, etc.), I committed something similar to the hack proposed in [0]. Bruno Haible skribis: > If I were you, I would start using the gnulib-tool option --local

Re: Accessing the environment's locale encoding settings

l...@gnu.org (Ludovic Courtès) writes: > It’s not completely satisfying either because --locale is not in > 2.0.[0-3], so users who really need it will need some configury; > furthermore, from 2.2.x on, it will be mostly unneeded. > > Yet, a choice has to be made between this hack and the other one

Re: Accessing the environment's locale encoding settings

l...@gnu.org (Ludovic Courtès) writes: > Hi Mike, > > Mike Gran skribis: > >> Here's a suggestion.  One could add an option to the guile >> interpreter's command line args (--locale=ARG perhaps) that has the >> effect of calling setlocale(LC_ALL,"ARG") first thing.  If --locale >> is called with 

Re: Accessing the environment's locale encoding settings

> From: Ludovic Courtès >> Here's a suggestion.  One could add an option to the guile > interpreter's command >> line args (--locale=ARG perhaps) that has the effect of calling >> setlocale(LC_ALL,"ARG") first thing.  If --locale is called > with no ARG >> specified, it would call to setloc

Re: Accessing the environment's locale encoding settings

Hi Mike, Mike Gran skribis: > Here's a suggestion.  One could add an option to the guile interpreter's > command > line args (--locale=ARG perhaps) that has the effect of calling > setlocale(LC_ALL,"ARG") first thing.  If --locale is called with no ARG > specified, it would call to setlocale(LC

Re: Accessing the environment's locale encoding settings

[CCing bug-gnulib. This is a reply to ]. Hi Ludovic, > I’m now convinced that an implicit setlocale(LC_ALL, "") is the right > thing for ‘master’. Good, glad that I could help with my opinion :) > For 2.0, though, this brings

Re: Accessing the environment's locale encoding settings

>From: Ludovic Courtès >>Bruno Haible skribis: > >> No, I'm suggesting to let the Scheme code know that is it using the user's >> locale. >> >> Yes, this is a backward-incompatible change, so probably you won't want to >> do it on the guile 2.0.x branch, and you will want to advertise it in the >

Re: Accessing the environment's locale encoding settings

Hi Bruno, Bruno Haible skribis: > No, I'm suggesting to let the Scheme code know that is it using the user's > locale. > > Yes, this is a backward-incompatible change, so probably you won't want to > do it on the guile 2.0.x branch, and you will want to advertise it in the > release notes or NEW

Re: Accessing the environment's locale encoding settings

Ludovic Courtès wrote: > It seems to me that the implicit call is often desirable, but at the > same time, it imposes a policy on the application. In C, Guile, & co., > the application can choose to ignore the locale, or to just honor > LC_CTYPE, or to set something different. What it actually do

Re: Accessing the environment's locale encoding settings

Noah Lavine writes: > It seems like the right thing to do might be to do setlocale(LC_ALL, > "") in Guile's main(). Let me argue that this accomplishes two goals > which we want to accomplish I agree wholeheartedly; this should be the default behavior. In the rare cases where the user needs to a

Re: Accessing the environment's locale encoding settings

Noah Lavine writes: > It seems like the right thing to do might be to do setlocale(LC_ALL, > "") in Guile's main(). Let me argue that this accomplishes two goals > which we want to accomplish That seems entirely reasonable to me, as long as libguile users can still set a non-environment locale b

Re: Accessing the environment's locale encoding settings

Hello, It seems like the right thing to do might be to do setlocale(LC_ALL, "") in Guile's main(). Let me argue that this accomplishes two goals which we want to accomplish - it does the right thing by default: you want your program to be able to talk to the user in the user's own language. This

Re: Accessing the environment's locale encoding settings

Hi Bruno, Thanks for your quick and insightful feedback. Bruno Haible skribis: > That is precisely the point. Only in C, C++, Objective C, PHP, and Guile, > it is the user's responsibility to set the locale. Look at the many > internationalization samples ("hello world" samples) in GNU gettext:

Re: Accessing the environment's locale encoding settings

[Dropping bug-libunistring from the CC.] Hi Ludo', > Should we be checking for charset aliases? Yes, without the system dependent aliases table the locale_charset() function is buggy on nearly all platforms. Cf. gnulib/lib/config.charset. > In Guile, strings coming from the C world are assumed

Accessing the environment's locale encoding settings

Hi Bruno, In Guile, strings coming from the C world are assumed to be encoded in the current locale encoding. Like in C, the current locale is set using ‘setlocale’, and it’s up to the user to write (setlocale LC_ALL "") to set the locale according to the relevant environment variables. The prob