GNU bug report logs - #39248
format-time-string ignores user's preferred locale

Previous Next

Package: emacs;

Reported by: "Paul W. Rankin" <hello <at> paulwrankin.com>

Date: Thu, 23 Jan 2020 03:54:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39248 in the body.
You can then email your comments to 39248 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 03:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Paul W. Rankin" <hello <at> paulwrankin.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 23 Jan 2020 03:54:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul W. Rankin" <hello <at> paulwrankin.com>
To: bug-gnu-emacs <at> gnu.org
Subject: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 13:48:16 +1000
Calling function (format-time-string "%x") will output incorrect time
string, ignoring user's preferred locale.

* Steps to reproduce:

1. ensure locale is correct with M-x getenv RET LANG RET
    -> en_AU.UTF-8
2. M-: (format-time-string "%x") RET
    -> "01/23/20"
3. repeat for env LC_TIME

* Expected results:

The format for %x as per the docs:
    %x is the locale’s "preferred" date format.

en_AU locale's "preferred" date format should be DD/MM/YYYY:
"23/01/2020"

i.e. the same as output from shell:
    $ locale
    LANG="en_AU.UTF-8"
    LC_COLLATE="en_AU.UTF-8"
    LC_CTYPE="en_AU.UTF-8"
    LC_MESSAGES="en_AU.UTF-8"
    LC_MONETARY="en_AU.UTF-8"
    LC_NUMERIC="en_AU.UTF-8"
    LC_TIME="en_AU.UTF-8"
    LC_ALL=
    $ date +%x
    23/01/2020

* Actual results:

"01/23/20"

GNU Emacs 27.0.60 (build 1, x86_64-apple-darwin19.2.0, NS appkit-1894.20
Version 10.15.2 (Build 19C57)) of 2020-01-18




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 05:57:01 GMT) Full text and rfc822 format available.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org, "Paul W. Rankin" <hello <at> paulwrankin.com>,
 39248 <at> debbugs.gnu.org
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 07:56:29 +0200
On January 23, 2020 5:48:16 AM GMT+02:00, "Paul W. Rankin" <hello <at> paulwrankin.com> wrote:
> Calling function (format-time-string "%x") will output incorrect time
> string, ignoring user's preferred locale.
> 
> * Steps to reproduce:
> 
> 1. ensure locale is correct with M-x getenv RET LANG RET
>     -> en_AU.UTF-8
> 2. M-: (format-time-string "%x") RET
>     -> "01/23/20"
> 3. repeat for env LC_TIME
> 
> * Expected results:
> 
> The format for %x as per the docs:
>     %x is the locale’s "preferred" date format.


What is your value of system-time-locale?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 05:57:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 06:45:02 GMT) Full text and rfc822 format available.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul W. Rankin" <hello <at> paulwrankin.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39248 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 16:44:11 +1000
On Thu, Jan 23 2020, Eli Zaretskii wrote:
>
> What is your value of system-time-locale?

system-time-locale -> nil

So, this works:

    (setq system-time-locale (getenv "LANG"))
    (format-time-string "%x")
    -> "23/01/2020"

But in the Elisp manual:

 -- Variable: system-time-locale
     This variable specifies the locale to use for formatting time
     values.  Changing the locale can cause messages to appear according
     to the conventions of a different language.  If the variable is
     ‘nil’, the locale is specified by environment variables in the
     usual POSIX fashion.

So the issue appears to be instead that ^this doesn't seem to be
happening...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 06:45:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 08:39:01 GMT) Full text and rfc822 format available.

Message #20 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Paul W. Rankin" <hello <at> paulwrankin.com>
Cc: 39248 <at> debbugs.gnu.org
Subject: Re: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 00:38:38 -0800
Thanks for the bug report. I don't observe the problem on GNU/Linux; for 
example, the following shell command:

LC_ALL=en_AU.utf8 emacs -Q -batch -eval '(message "%s" (format-time-string "%x"))'

outputs "23/01/20", which is the same thing that the shell command 
"LC_ALL=en_AU.utf8 date +%x" outputs. I don't have easy access to macOS so I'll 
need your help to debug this.

I suggest that you build Emacs with debug symbols and with optimization off 
(e.g., "make clean; make CFLAGS='-g3 -O0'"), and then run it under a debugger, 
and plant a breakpoint on the nstrftime function and then single-step and see 
what goes wrong. Something like this:

$ make clean
$ make CFLAGS='-g3 -O0'
$ gdb src/emacs
(gdb) b nstrftime
(gdb) r -Q -batch -eval '(message "%s" (format-time-string "%x"))'
(gdb) n
(gdb) n
...

This will help us see whether the bug is in Emacs or in the underlying strftime 
function.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 13:13:01 GMT) Full text and rfc822 format available.

Message #23 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Paul W. Rankin <hello <at> paulwrankin.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39248 <at> debbugs.gnu.org
Subject: Re: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 23:12:39 +1000
Thanks for looking into this for me.

> On 23 Jan 2020, at 6:38 pm, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> 
> Thanks for the bug report. I don't observe the problem on GNU/Linux; for example, the following shell command:
> 
> LC_ALL=en_AU.utf8 emacs -Q -batch -eval '(message "%s" (format-time-string "%x"))'

This outputs "01/23/20" for me. But I think this is because "utf8" vs "utf-8", e.g.

LC_ALL=en_au.utf-8 emacs -Q -batch -eval '(message "%s" (format-time-string "%x"))'
-> 23/01/2020

Which would indicate that macOS only recognises "utf-8" not "utf8".

LC_ALL=en_AU.utf8 date +%x
-> 01/23/20
LC_ALL=en_AU.utf-8 date +%x
-> 23/01/2020

I should note though that the issue only presents from Emacs.app i.e. when launched from Finder.

Even when launching Emacs.app via
/Applications/Emacs.app/Contents/MacOS/Emacs -Q
I can get the correct date.

It's solely when the app is launched from Finder i.e. outside the shell. AFAIK this means there's no way for me to launch Emacs.app outside of the shell with the -Q flag and so I moved my init files out of the way for a clean launch and reproduced that way.

I've also reproduced on Emacs.app versions 24 and 25. (It's actually an issue that has bothered me for years.)


> I suggest that you build Emacs with debug symbols and with optimization off (e.g., "make clean; make CFLAGS='-g3 -O0'"), and then run it under a debugger, and plant a breakpoint on the nstrftime function and then single-step and see what goes wrong. Something like this:
> 
> $ make clean
> $ make CFLAGS='-g3 -O0'
> $ gdb src/emacs
> (gdb) b nstrftime
> (gdb) r -Q -batch -eval '(message "%s" (format-time-string "%x"))'
> (gdb) n
> (gdb) n
> ...

I installed gdb and followed these steps, but I get a codesigning error; apparently in order to function on macOS, gdb requires some "code-signing" steps that are beyond my competency level.

Is there another way to test the strftime function?

Or, given that the issue is isolated to Emacs.app when launched outside of the shell environment, does that narrow it down at all?






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 14:20:02 GMT) Full text and rfc822 format available.

Message #26 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul W. Rankin" <hello <at> paulwrankin.com>
Cc: 39248 <at> debbugs.gnu.org
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 16:19:21 +0200
> From: "Paul W. Rankin" <hello <at> paulwrankin.com>
> Cc: bug-gnu-emacs <at> gnu.org, 39248 <at> debbugs.gnu.org
> Date: Thu, 23 Jan 2020 16:44:11 +1000
> 
> So, this works:
> 
>     (setq system-time-locale (getenv "LANG"))
>     (format-time-string "%x")
>     -> "23/01/2020"
> 
> But in the Elisp manual:
> 
>  -- Variable: system-time-locale
>      This variable specifies the locale to use for formatting time
>      values.  Changing the locale can cause messages to appear according
>      to the conventions of a different language.  If the variable is
>      ‘nil’, the locale is specified by environment variables in the
>      usual POSIX fashion.
> 
> So the issue appears to be instead that ^this doesn't seem to be
> happening...

No, having system-time-locale as nil is perfectly normal.  I asked the
question so we'd know whether that variable is part of the issue.  It
doesn't seem to be, AFAIU.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 18:06:02 GMT) Full text and rfc822 format available.

Message #29 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul W. Rankin <hello <at> paulwrankin.com>
Cc: 39248 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 20:05:22 +0200
> From: Paul W. Rankin <hello <at> paulwrankin.com>
> Date: Thu, 23 Jan 2020 23:12:39 +1000
> Cc: 39248 <at> debbugs.gnu.org
> 
> Or, given that the issue is isolated to Emacs.app when launched outside of the shell environment, does that narrow it down at all?

I guess that's yet another manifestation of the macOS deviant behavior
of Emacs.app, whereby it doesn't inherit environment variables from
the shell.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Thu, 23 Jan 2020 22:06:01 GMT) Full text and rfc822 format available.

Message #32 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39248 <at> debbugs.gnu.org, "Paul W. Rankin" <hello <at> paulwrankin.com>,
 eggert <at> cs.ucla.edu
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 17:04:59 -0500
Eli Zaretskii wrote:

>> Or, given that the issue is isolated to Emacs.app when launched
>> outside of the shell environment, does that narrow it down at all?
>
> I guess that's yet another manifestation of the macOS deviant behavior
> of Emacs.app, whereby it doesn't inherit environment variables from
> the shell.

Rather, that macOS does not set up environment for applications
launched from Finder. I don't think that is an Emacs problem.

On GNU/Linux, my window manager runss from a login shell and so has a
correct environment for applications it launches.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Fri, 24 Jan 2020 03:18:01 GMT) Full text and rfc822 format available.

Message #35 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: "Paul W. Rankin" <hello <at> paulwrankin.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 39248 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Fri, 24 Jan 2020 13:17:11 +1000
> On 24 Jan 2020, at 8:04 am, Glenn Morris <rgm <at> gnu.org> wrote:
> 
> Eli Zaretskii wrote:
> 
>>> Or, given that the issue is isolated to Emacs.app when launched
>>> outside of the shell environment, does that narrow it down at all?
>> 
>> I guess that's yet another manifestation of the macOS deviant behavior
>> of Emacs.app, whereby it doesn't inherit environment variables from
>> the shell.
> 
> Rather, that macOS does not set up environment for applications
> launched from Finder. I don't think that is an Emacs problem.
> 
> On GNU/Linux, my window manager runss from a login shell and so has a
> correct environment for applications it launches.

It would probably be weird for macOS to ask the shell for environment variables when launched from the Finder. The relationship doesn't appear as the same as on GNU/Linux.

But OS-preferences aside, Emacs.app in macOS does correctly set the process-environment variable though, so these environment variables (including LANG) are available to Emacs, e.g. USER, TMPDIR, SHELL are a few that seem to be picked up without issue, so shouldn't the same be true of LANG?



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Fri, 24 Jan 2020 07:36:02 GMT) Full text and rfc822 format available.

Message #38 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Paul W. Rankin" <hello <at> paulwrankin.com>, Glenn Morris <rgm <at> gnu.org>
Cc: 39248 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Alan Third <alan <at> idiocy.org>
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Thu, 23 Jan 2020 23:35:20 -0800
[Message part 1 (text/plain, inline)]
On 1/23/20 7:17 PM, Paul W. Rankin wrote:
> The relationship doesn't appear as the same as on GNU/Linux.

It's similar, in that one can launch apps in various ways (e.g., via Gnome) 
without involving shell environment variables.

Looking into this a bit more, I see that Alan Third wrote a fix for this problem 
(which is apparently quite a zoo in macOS, as Apple keeps changing how to set 
environment variables!) into Emacs in master commit 
2016-02-11T02:26:50Z!alan <at> idiocy.org. However, Emacs currently sets the LANG 
environment variable in ns_init_locale *after* Emacs uses LANG to set the 
LC_TIME locale, which is not what is wanted here. So, please try the attached 
patch to master. You'll need to grab the latest master as I recently installed a 
locale cleanup patch while looking into this mess.

If this patch doesn't work for you, perhaps you can write a small variant of it 
that does work.
[0001-Propagate-NSLocale-into-Emacs-better.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Sat, 25 Jan 2020 09:37:02 GMT) Full text and rfc822 format available.

Message #41 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: "Paul W. Rankin" <hello <at> paulwrankin.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 Alan Third <alan <at> idiocy.org>, 39248 <at> debbugs.gnu.org
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Sat, 25 Jan 2020 19:36:03 +1000
On Fri, Jan 24 2020, Paul Eggert wrote:
> However, Emacs currently sets the LANG environment variable in
> ns_init_locale *after* Emacs uses LANG to set the LC_TIME locale,
> which is not what is wanted here. So, please try the attached patch to
> master.

Thank you, this patch works; Emacs.app launched from Finder on macOS now
gives:

    (format-time-string "%x")
    "25/01/2020"

GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.2.0, NS appkit-1894.20
Version 10.15.2 (Build 19C57)) of 2020-01-25




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Sat, 25 Jan 2020 11:19:02 GMT) Full text and rfc822 format available.

Message #44 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, "Paul W. Rankin" <hello <at> paulwrankin.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 39248 <at> debbugs.gnu.org
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Sat, 25 Jan 2020 11:18:05 +0000
On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
>  #ifdef HAVE_NS
>    ns_pool = ns_alloc_autorelease_pool ();
> -#ifdef NS_IMPL_GNUSTEP
> -  /* GNUstep stupidly resets our locale settings after we made them.  */
> -  fixup_locale ();
> -#endif

Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
that code above any more?

Thanks!
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Sat, 25 Jan 2020 11:43:02 GMT) Full text and rfc822 format available.

Message #47 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: "Paul W. Rankin" <hello <at> paulwrankin.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Glenn Morris <rgm <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>, 39248 <at> debbugs.gnu.org
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Sat, 25 Jan 2020 21:42:16 +1000
> On 25 Jan 2020, at 9:18 pm, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
>> #ifdef HAVE_NS
>>   ns_pool = ns_alloc_autorelease_pool ();
>> -#ifdef NS_IMPL_GNUSTEP
>> -  /* GNUstep stupidly resets our locale settings after we made them.  */
>> -  fixup_locale ();
>> -#endif
> 
> Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> that code above any more?

I have no idea sorry. Applying the patch and compiling was a new experience for me. If someone held a gun to my head I wouldn't even be sure it's C code...

Is there anything you'd like me to do with the Emacs.app to check it's kosher?



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Sat, 25 Jan 2020 12:04:01 GMT) Full text and rfc822 format available.

Message #50 received at 39248 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: "Paul W. Rankin" <hello <at> paulwrankin.com>
Cc: Glenn Morris <rgm <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>, 39248 <at> debbugs.gnu.org
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Sat, 25 Jan 2020 12:03:49 +0000
On Sat, Jan 25, 2020 at 09:42:16PM +1000, Paul W. Rankin wrote:
> 
> > On 25 Jan 2020, at 9:18 pm, Alan Third <alan <at> idiocy.org> wrote:
> > 
> > On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
> >> #ifdef HAVE_NS
> >>   ns_pool = ns_alloc_autorelease_pool ();
> >> -#ifdef NS_IMPL_GNUSTEP
> >> -  /* GNUstep stupidly resets our locale settings after we made them.  */
> >> -  fixup_locale ();
> >> -#endif
> > 
> > Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> > that code above any more?
> 
> I have no idea sorry. Applying the patch and compiling was a new
> experience for me. If someone held a gun to my head I wouldn't even
> be sure it's C code...
> 
> Is there anything you'd like me to do with the Emacs.app to check
> it's kosher?

No, you’re good. I was actually talking to the other Paul who wrote
the patch. :)
-- 
Alan Third




Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Sun, 26 Jan 2020 08:36:01 GMT) Full text and rfc822 format available.

Notification sent to "Paul W. Rankin" <hello <at> paulwrankin.com>:
bug acknowledged by developer. (Sun, 26 Jan 2020 08:36:01 GMT) Full text and rfc822 format available.

Message #55 received at 39248-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Third <alan <at> idiocy.org>
Cc: Glenn Morris <rgm <at> gnu.org>, "Paul W. Rankin" <hello <at> paulwrankin.com>,
 39248-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Sun, 26 Jan 2020 00:35:31 -0800
On 1/25/20 3:18 AM, Alan Third wrote:
> On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
>>   #ifdef HAVE_NS
>>     ns_pool = ns_alloc_autorelease_pool ();
>> -#ifdef NS_IMPL_GNUSTEP
>> -  /* GNUstep stupidly resets our locale settings after we made them.  */
>> -  fixup_locale ();
>> -#endif
> 
> Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> that code above any more?

Although I don't use GNUstep and haven't tested the code, as I recall GNUstep 
initializes itself on its first call (which is why the fixup_locale call was 
there, as ns_alloc_autorelease_pool was the first call to GNUstep), and if so 
then we don't need fixup_locale there anymore since we now call fixup_locale 
earlier, just after calling ns_init_locale which calls NSLocale currentlocale 
should cause GNUstep to initialize itself.

If I'm wrong feel free to put that code back in, but in the meantime I installed 
the patch as-is, as Paul R. reports that it works for him.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#39248; Package emacs. (Sun, 26 Jan 2020 10:27:01 GMT) Full text and rfc822 format available.

Message #58 received at 39248-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, "Paul W. Rankin" <hello <at> paulwrankin.com>,
 39248-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39248: format-time-string ignores user's preferred locale
Date: Sun, 26 Jan 2020 10:26:00 +0000
On Sun, Jan 26, 2020 at 12:35:31AM -0800, Paul Eggert wrote:
> On 1/25/20 3:18 AM, Alan Third wrote:
> > On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
> > >   #ifdef HAVE_NS
> > >     ns_pool = ns_alloc_autorelease_pool ();
> > > -#ifdef NS_IMPL_GNUSTEP
> > > -  /* GNUstep stupidly resets our locale settings after we made them.  */
> > > -  fixup_locale ();
> > > -#endif
> > 
> > Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> > that code above any more?
> 
> Although I don't use GNUstep and haven't tested the code, as I recall
> GNUstep initializes itself on its first call (which is why the fixup_locale
> call was there, as ns_alloc_autorelease_pool was the first call to GNUstep),
> and if so then we don't need fixup_locale there anymore since we now call
> fixup_locale earlier, just after calling ns_init_locale which calls NSLocale
> currentlocale should cause GNUstep to initialize itself.
> 
> If I'm wrong feel free to put that code back in, but in the meantime I
> installed the patch as-is, as Paul R. reports that it works for him.

No, sounds reasonable. Thanks for the explanation.
-- 
Alan Third




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 23 Feb 2020 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 35 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.