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