Emacs OS X GUI doesn't set locale

Emacs OS X GUI doesn't set locale

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

I've raised a bug (bug#22392) about Emacs on OS X not setting the locale
and character encodings when launched from the GUI (finder, spotlight,
etc.). As far as I can tell it's because Emacs looks at LC_ALL, LC_TYPE
and LANG for the locale information, but it's not set when launched from
the GUI. It IS set in terminal.app, so if you launch from there it all
looks good.

Apparently the Windows version has the same problem and sorts it by
setting LANG from a function called early in in main in emacs.c.

I've written a patch that copies this method. It calls the NextStep
function for getting the locale and then sets LANG if it's not already
set. I'm not sure that's it's the best way of doing it. I had to create
a new Objective C file and header to include in emacs.c.

There was also a question raised about what the correct character
encodings are for OS X. On my machine it sets LANG to en_GB and most of
the character encodings to iso-latin-1-unix, which looks OK to me, but
it was suggested that they should be UTF-8.

Does anyone know what the correct encodings are on OS X?


[-- Attachment #2: OS X Locale fix --]
[-- Type: text/plain, Size: 4560 bytes --]

From 85d5d2f0213e052d1eccb6dc9e00f090b894ef90 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sun, 17 Jan 2016 13:56:12 +0000
Subject: [PATCH] Set locale when run from OS X GUI

* configure.ac: Add nsinit.o to NS_OBJC_OBJ and link the Foundation
framework.
* src/emacs.c (main): Include nsinit.h and run init_environment.
* src/nsinit.c (init_environment): Get locale from OS and set LANG.
* src/nsinit.h: header for including nsinit.c.
---
 configure.ac |  4 ++--
 src/emacs.c  |  8 ++++++++
 src/nsinit.h | 20 ++++++++++++++++++++
 src/nsinit.m | 33 +++++++++++++++++++++++++++++++++
 4 files changed, 63 insertions(+), 2 deletions(-)
 create mode 100644 src/nsinit.h
 create mode 100644 src/nsinit.m

diff --git a/configure.ac b/configure.ac
index 6c9b621..7f61344 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1892,7 +1892,7 @@ if test "${HAVE_NS}" = yes; then
      INSTALL_ARCH_INDEP_EXTRA=
   fi
 
-  NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o $ns_fontfile"
+  NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o nsinit.o $ns_fontfile"
 fi
 CFLAGS="$tmp_CFLAGS"
 CPPFLAGS="$tmp_CPPFLAGS"
@@ -5083,7 +5083,7 @@ case "$opsys" in
    ## only costs about 1.5K of wasted binary space.
    headerpad_extra=1000
    if test "$HAVE_NS" = "yes"; then
-     libs_nsgui="-framework AppKit"
+     libs_nsgui="-framework AppKit -framework Foundation"
      if test "$NS_IMPL_COCOA" = "yes"; then
         libs_nsgui="$libs_nsgui -framework IOKit"
      fi
diff --git a/src/emacs.c b/src/emacs.c
index b1b2170..9473bcd 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -56,6 +56,10 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #include <binary-io.h>
 #endif
 
+#ifdef HAVE_NS
+#include "nsinit.h"
+#endif
+
 #ifdef HAVE_WINDOW_SYSTEM
 #include TERM_HEADER
 #endif /* HAVE_WINDOW_SYSTEM */
@@ -1371,6 +1375,10 @@ Using an Emacs configured with --with-x-toolkit=lucid does not have this problem
   init_ntproc (dumping); /* must precede init_editfns.  */
 #endif
 
+#ifdef HAVE_NS
+  init_environment();
+#endif
+
   /* Initialize and GC-protect Vinitial_environment and
      Vprocess_environment before set_initial_environment fills them
      in.  */
diff --git a/src/nsinit.h b/src/nsinit.h
new file mode 100644
index 0000000..41b79c8
--- /dev/null
+++ b/src/nsinit.h
@@ -0,0 +1,20 @@
+/* Definitions for initialising NeXT/Open/GNUstep environment
+   Copyright (C) 2016 Free Software Foundation,
+   Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
+
+void init_environment (void);
diff --git a/src/nsinit.m b/src/nsinit.m
new file mode 100644
index 0000000..32281a6
--- /dev/null
+++ b/src/nsinit.m
@@ -0,0 +1,33 @@
+/* NeXT/Open/GNUstep / MacOSX initialisation functions.      -*- coding: utf-8 -*-
+
+Copyright (C) 1989, 1993-1994, 2005-2006, 2008-2016 Free Software
+Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#include <config.h>
+#include <Foundation/Foundation.h>
+
+/* Set up the environment in cases where Emacs has been run from the
+   GUI and therefore has missing environment variables. */
+void
+init_environment (void)
+{
+    const char * locale = [[[NSLocale currentLocale] localeIdentifier] UTF8String];
+
+    /* Set LANG to locale, but not if LANG is already set. */
+    setenv("LANG", locale, 0);
+}
-- 
2.5.4 (Apple Git-61)


[-- Attachment #3: Type: text/plain, Size: 17 bytes --]



-- 
Alan Third

Re: Emacs OS X GUI doesn't set locale

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 6632 bytes --]

Hi,

This sounds like a good change. Unfortunately, I can't answer the
locale-questions you raised in the mail. However, I have a few small
questions:

* Why a separate source file? Is there any technical reasons why this
couldn't reside in, say, nsterm.m?

* Can you add a "NSTRACE" line to the function, so that it's clear when
this function is called, when NSTRACE is enabled.

* Have you considered populating `process-environment' instead of setting
LANG in the Emacs process? Would there be any advantages/disadvantages with
this approach?

    -- Anders Lindgren

On Mon, Jan 25, 2016 at 11:18 PM, Alan Third <alan@idiocy.org> wrote:

> I've raised a bug (bug#22392) about Emacs on OS X not setting the locale
> and character encodings when launched from the GUI (finder, spotlight,
> etc.). As far as I can tell it's because Emacs looks at LC_ALL, LC_TYPE
> and LANG for the locale information, but it's not set when launched from
> the GUI. It IS set in terminal.app, so if you launch from there it all
> looks good.
>
> Apparently the Windows version has the same problem and sorts it by
> setting LANG from a function called early in in main in emacs.c.
>
> I've written a patch that copies this method. It calls the NextStep
> function for getting the locale and then sets LANG if it's not already
> set. I'm not sure that's it's the best way of doing it. I had to create
> a new Objective C file and header to include in emacs.c.
>
> There was also a question raised about what the correct character
> encodings are for OS X. On my machine it sets LANG to en_GB and most of
> the character encodings to iso-latin-1-unix, which looks OK to me, but
> it was suggested that they should be UTF-8.
>
> Does anyone know what the correct encodings are on OS X?
>
>
> From 85d5d2f0213e052d1eccb6dc9e00f090b894ef90 Mon Sep 17 00:00:00 2001
> From: Alan Third <alan@idiocy.org>
> Date: Sun, 17 Jan 2016 13:56:12 +0000
> Subject: [PATCH] Set locale when run from OS X GUI
>
> * configure.ac: Add nsinit.o to NS_OBJC_OBJ and link the Foundation
> framework.
> * src/emacs.c (main): Include nsinit.h and run init_environment.
> * src/nsinit.c (init_environment): Get locale from OS and set LANG.
> * src/nsinit.h: header for including nsinit.c.
> ---
>  configure.ac |  4 ++--
>  src/emacs.c  |  8 ++++++++
>  src/nsinit.h | 20 ++++++++++++++++++++
>  src/nsinit.m | 33 +++++++++++++++++++++++++++++++++
>  4 files changed, 63 insertions(+), 2 deletions(-)
>  create mode 100644 src/nsinit.h
>  create mode 100644 src/nsinit.m
>
> diff --git a/configure.ac b/configure.ac
> index 6c9b621..7f61344 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1892,7 +1892,7 @@ if test "${HAVE_NS}" = yes; then
>       INSTALL_ARCH_INDEP_EXTRA=
>    fi
>
> -  NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o
> $ns_fontfile"
> +  NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o nsinit.o
> $ns_fontfile"
>  fi
>  CFLAGS="$tmp_CFLAGS"
>  CPPFLAGS="$tmp_CPPFLAGS"
> @@ -5083,7 +5083,7 @@ case "$opsys" in
>     ## only costs about 1.5K of wasted binary space.
>     headerpad_extra=1000
>     if test "$HAVE_NS" = "yes"; then
> -     libs_nsgui="-framework AppKit"
> +     libs_nsgui="-framework AppKit -framework Foundation"
>       if test "$NS_IMPL_COCOA" = "yes"; then
>          libs_nsgui="$libs_nsgui -framework IOKit"
>       fi
> diff --git a/src/emacs.c b/src/emacs.c
> index b1b2170..9473bcd 100644
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -56,6 +56,10 @@ along with GNU Emacs.  If not, see <
> http://www.gnu.org/licenses/>.  */
>  #include <binary-io.h>
>  #endif
>
> +#ifdef HAVE_NS
> +#include "nsinit.h"
> +#endif
> +
>  #ifdef HAVE_WINDOW_SYSTEM
>  #include TERM_HEADER
>  #endif /* HAVE_WINDOW_SYSTEM */
> @@ -1371,6 +1375,10 @@ Using an Emacs configured with
> --with-x-toolkit=lucid does not have this problem
>    init_ntproc (dumping); /* must precede init_editfns.  */
>  #endif
>
> +#ifdef HAVE_NS
> +  init_environment();
> +#endif
> +
>    /* Initialize and GC-protect Vinitial_environment and
>       Vprocess_environment before set_initial_environment fills them
>       in.  */
> diff --git a/src/nsinit.h b/src/nsinit.h
> new file mode 100644
> index 0000000..41b79c8
> --- /dev/null
> +++ b/src/nsinit.h
> @@ -0,0 +1,20 @@
> +/* Definitions for initialising NeXT/Open/GNUstep environment
> +   Copyright (C) 2016 Free Software Foundation,
> +   Inc.
> +
> +This file is part of GNU Emacs.
> +
> +GNU Emacs is free software: you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation, either version 3 of the License, or
> +(at your option) any later version.
> +
> +GNU Emacs is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
> +
> +void init_environment (void);
> diff --git a/src/nsinit.m b/src/nsinit.m
> new file mode 100644
> index 0000000..32281a6
> --- /dev/null
> +++ b/src/nsinit.m
> @@ -0,0 +1,33 @@
> +/* NeXT/Open/GNUstep / MacOSX initialisation functions.      -*- coding:
> utf-8 -*-
> +
> +Copyright (C) 1989, 1993-1994, 2005-2006, 2008-2016 Free Software
> +Foundation, Inc.
> +
> +This file is part of GNU Emacs.
> +
> +GNU Emacs is free software: you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation, either version 3 of the License, or
> +(at your option) any later version.
> +
> +GNU Emacs is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
> +
> +#include <config.h>
> +#include <Foundation/Foundation.h>
> +
> +/* Set up the environment in cases where Emacs has been run from the
> +   GUI and therefore has missing environment variables. */
> +void
> +init_environment (void)
> +{
> +    const char * locale = [[[NSLocale currentLocale] localeIdentifier]
> UTF8String];
> +
> +    /* Set LANG to locale, but not if LANG is already set. */
> +    setenv("LANG", locale, 0);
> +}
> --
> 2.5.4 (Apple Git-61)
>
>
>
>
> --
> Alan Third
>
>

[-- Attachment #2: Type: text/html, Size: 8533 bytes --]

Re: Emacs OS X GUI doesn't set locale

[Eli Zaretskii]

> Date: Tue, 26 Jan 2016 08:11:13 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22392@debbugs.gnu.org, emacs-devel <emacs-devel@gnu.org>
> 
> * Have you considered populating `process-environment' instead of setting LANG
> in the Emacs process? Would there be any advantages/disadvantages with this
> approach?

process-environment gets passed to child processes, right?

Re: Emacs OS X GUI doesn't set locale

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Tue, Jan 26, 2016 at 3:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > * Have you considered populating `process-environment' instead of
> setting LANG
> > in the Emacs process? Would there be any advantages/disadvantages with
> this
> > approach?
>
> process-environment gets passed to child processes, right?
>

Yes, that is why I asked if he had considered that approach. The reason I
asked was if there was any advantage in setting the LANG variable of the
Emacs process itself, or if this only was of interest of subprocesses.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 947 bytes --]

Re: Emacs OS X GUI doesn't set locale

[Eli Zaretskii]

> Date: Tue, 26 Jan 2016 16:06:38 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22392@debbugs.gnu.org, Alan Third <alan@idiocy.org>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
>     > * Have you considered populating `process-environment' instead of setting
>     LANG
>     > in the Emacs process? Would there be any advantages/disadvantages with
>     this
>     > approach?
>     
>     process-environment gets passed to child processes, right?
>     
> 
> Yes, that is why I asked if he had considered that approach. The reason I asked
> was if there was any advantage in setting the LANG variable of the Emacs
> process itself, or if this only was of interest of subprocesses.

Passing our LANG to subprocesses would be a bad idea, I think.  Emacs
is not supposed to change the environment of the child processes just
because it needs that for itself.

Re: Emacs OS X GUI doesn't set locale

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

>
> > Yes, that is why I asked if he had considered that approach. The reason
> I asked
> > was if there was any advantage in setting the LANG variable of the Emacs
> > process itself, or if this only was of interest of subprocesses.
>
> Passing our LANG to subprocesses would be a bad idea, I think.  Emacs
> is not supposed to change the environment of the child processes just
> because it needs that for itself.
>

My mistake. I though the whole point was to set it for subprocesses (for
example, to make "ls" sort file names in the right order). Reading the post
again, I realise that this is not the case.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 937 bytes --]

Re: Emacs OS X GUI doesn't set locale

[Alan Third]

Eli Zaretskii <eliz@gnu.org> writes:

>> Yes, that is why I asked if he had considered that approach. The reason I asked
>> was if there was any advantage in setting the LANG variable of the Emacs
>> process itself, or if this only was of interest of subprocesses.
>
> Passing our LANG to subprocesses would be a bad idea, I think.  Emacs
> is not supposed to change the environment of the child processes just
> because it needs that for itself.

To my mind it might be a plus for Emacs to pass it's LANG along in this
particular situation as UNIX style sub-processes aren't going to pick up
the correct locale themselves and so will, presumably, default to "C",
no matter what the locale should be.

eg. running the locale command from within Emacs:

LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

vs running it from terminal.app:

LANG="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_CTYPE="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_ALL=

-- 
Alan Third

Re: Emacs OS X GUI doesn't set locale

[Paul Eggert]

On 01/26/2016 03:05 PM, Alan Third wrote:
> To my mind it might be a plus for Emacs to pass it's LANG along in this
> particular situation

Yes, this sounds right. We can think of it as OS X having a screwy way 
to specify the locale, for GUI-launched applications; it doesn't bother 
to specify LC_ALL etc. and expects the application to do that. So Emacs 
should do that at the start, as if the user had done it before launching 
Emacs.

I looked around, and it appears the GnuCash ran into a similar problem. 
You might want to look at its solution, in:

https://github.com/Gnucash/gnucash/blob/master/src/bin/gnucash-bin.c

Re: Emacs OS X GUI doesn't set locale

[Eli Zaretskii]

> Cc: 22392@debbugs.gnu.org, Anders Lindgren <andlind@gmail.com>,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 27 Jan 2016 10:06:45 -0800
> 
> On 01/26/2016 03:05 PM, Alan Third wrote:
> > To my mind it might be a plus for Emacs to pass it's LANG along in this
> > particular situation
> 
> Yes, this sounds right.

I think passing that LANG to subprocesses will cause bug reports.

Re: Emacs OS X GUI doesn't set locale

[Paul Eggert]

On 01/27/2016 11:44 AM, Eli Zaretskii wrote:
> I think passing that LANG to subprocesses will cause bug reports.
>

Quite possibly, yes. However, my guess is that it will cause fewer bug 
reports than what Emacs is doing now.

Under MS-Windows, w32.c's init_environment sets LANG if not already set, 
so there is some precedent for OS X doing something similar.

Re: Emacs OS X GUI doesn't set locale

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 01/26/2016 03:05 PM, Alan Third wrote:
>
> I looked around, and it appears the GnuCash ran into a similar
> problem. You might want to look at its solution, in:
>
> https://github.com/Gnucash/gnucash/blob/master/src/bin/gnucash-bin.c


I've had a look at that code and was initially worried at how much more
they have than I'd written, but I'm pretty sure that most of their code
is doing things that are done by mule in emacs.

One thing I don't understand is that they're building up the locale
value from the two parts (language and country code) when NSLocale
provides a function that does that for you. Makes me wonder if they know
something I don't.

They've also wrapped that bit of code in a try/catch as someone was
apparently getting a crash due to not having the country code set. I
can't replicate this, the only way I've found through Google is by using
XCode to unset the user's locale, and we don't use XCode.

I've put in a try/catch anyway, just in case.


[-- Attachment #2: OS X Locale fix --]
[-- Type: text/plain, Size: 2294 bytes --]

From b96c97cb16a980243389c01c10c5ab232fe6827e Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Thu, 28 Jan 2016 21:42:04 +0000
Subject: [PATCH] Set locale when run from OS X GUI

* src/emacs.c (main): Call ns_init_locale.
* src/nsterm.m (ns_init_locale): Get locale from OS and set LANG.
* src/nsterm.h: Include ns_init_locale.
---
 src/emacs.c  |  5 +++++
 src/nsterm.h |  2 ++
 src/nsterm.m | 21 +++++++++++++++++++++
 3 files changed, 28 insertions(+)

diff --git a/src/emacs.c b/src/emacs.c
index aaf058e..10e81d5 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -1378,6 +1378,11 @@ Using an Emacs configured with --with-x-toolkit=lucid does not have this problem
   init_ntproc (dumping); /* must precede init_editfns.  */
 #endif
 
+#ifdef HAVE_NS
+  /* Initialise the locale from user defaults. */
+  ns_init_locale();
+#endif
+
   /* Initialize and GC-protect Vinitial_environment and
      Vprocess_environment before set_initial_environment fills them
      in.  */
diff --git a/src/nsterm.h b/src/nsterm.h
index 6ca584e..fa5399c 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -1141,6 +1141,8 @@ extern void  ns_retain_object (void *obj);
 extern void *ns_alloc_autorelease_pool (void);
 extern void ns_release_autorelease_pool (void *);
 extern const char *ns_get_defaults_value (const char *key);
+extern void ns_init_locale (void);
+
 
 /* in nsmenu */
 extern void update_frame_tool_bar (struct frame *f);
diff --git a/src/nsterm.m b/src/nsterm.m
index b270e0e..4b04fd5 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -586,6 +586,27 @@ ns_load_path (void)
 
 
 void
+ns_init_locale (void)
+/* OS X doesn't set any environment variables for the locale when run
+   from the GUI. Get the locale from the OS and set LANG. */
+{
+  NSLocale *locale = [NSLocale currentLocale];
+
+  NSTRACE ("ns_init_locale");
+
+  @try
+    {
+      /* Set LANG to locale, but not if LANG is already set. */
+      setenv("LANG", [[locale localeIdentifier] UTF8String], 0);
+    }
+  @catch (NSException *e)
+    {
+      NSLog (@"Locale detection failed: %@: %@", [e name], [e reason]);
+    }
+}
+
+
+void
 ns_release_object (void *obj)
 /* --------------------------------------------------------------------------
     Release an object (callable from C)
-- 
2.5.4 (Apple Git-61)


[-- Attachment #3: Type: text/plain, Size: 16 bytes --]


-- 
Alan Third

Re: Emacs OS X GUI doesn't set locale

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 4003 bytes --]

Hi!

Today, I tested this patch on OS X and GNUstep. From what I can see, it
applies cleanly and work as intended.

As the LANG variable is set early in the initialisation process, it will be
propagated to `process-environment' and thus set for all processes started
by Emacs.

I suggest that we apply this patch, so that it will be included in the next
Emacs 25 pretest.

    -- Anders Lindgren

On Thu, Jan 28, 2016 at 11:53 PM, Alan Third <alan@idiocy.org> wrote:

> Paul Eggert <eggert@cs.ucla.edu> writes:
>
> > On 01/26/2016 03:05 PM, Alan Third wrote:
> >
> > I looked around, and it appears the GnuCash ran into a similar
> > problem. You might want to look at its solution, in:
> >
> > https://github.com/Gnucash/gnucash/blob/master/src/bin/gnucash-bin.c
>
>
> I've had a look at that code and was initially worried at how much more
> they have than I'd written, but I'm pretty sure that most of their code
> is doing things that are done by mule in emacs.
>
> One thing I don't understand is that they're building up the locale
> value from the two parts (language and country code) when NSLocale
> provides a function that does that for you. Makes me wonder if they know
> something I don't.
>
> They've also wrapped that bit of code in a try/catch as someone was
> apparently getting a crash due to not having the country code set. I
> can't replicate this, the only way I've found through Google is by using
> XCode to unset the user's locale, and we don't use XCode.
>
> I've put in a try/catch anyway, just in case.
>
>
> From b96c97cb16a980243389c01c10c5ab232fe6827e Mon Sep 17 00:00:00 2001
> From: Alan Third <alan@idiocy.org>
> Date: Thu, 28 Jan 2016 21:42:04 +0000
> Subject: [PATCH] Set locale when run from OS X GUI
>
> * src/emacs.c (main): Call ns_init_locale.
> * src/nsterm.m (ns_init_locale): Get locale from OS and set LANG.
> * src/nsterm.h: Include ns_init_locale.
> ---
>  src/emacs.c  |  5 +++++
>  src/nsterm.h |  2 ++
>  src/nsterm.m | 21 +++++++++++++++++++++
>  3 files changed, 28 insertions(+)
>
> diff --git a/src/emacs.c b/src/emacs.c
> index aaf058e..10e81d5 100644
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -1378,6 +1378,11 @@ Using an Emacs configured with
> --with-x-toolkit=lucid does not have this problem
>    init_ntproc (dumping); /* must precede init_editfns.  */
>  #endif
>
> +#ifdef HAVE_NS
> +  /* Initialise the locale from user defaults. */
> +  ns_init_locale();
> +#endif
> +
>    /* Initialize and GC-protect Vinitial_environment and
>       Vprocess_environment before set_initial_environment fills them
>       in.  */
> diff --git a/src/nsterm.h b/src/nsterm.h
> index 6ca584e..fa5399c 100644
> --- a/src/nsterm.h
> +++ b/src/nsterm.h
> @@ -1141,6 +1141,8 @@ extern void  ns_retain_object (void *obj);
>  extern void *ns_alloc_autorelease_pool (void);
>  extern void ns_release_autorelease_pool (void *);
>  extern const char *ns_get_defaults_value (const char *key);
> +extern void ns_init_locale (void);
> +
>
>  /* in nsmenu */
>  extern void update_frame_tool_bar (struct frame *f);
> diff --git a/src/nsterm.m b/src/nsterm.m
> index b270e0e..4b04fd5 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -586,6 +586,27 @@ ns_load_path (void)
>
>
>  void
> +ns_init_locale (void)
> +/* OS X doesn't set any environment variables for the locale when run
> +   from the GUI. Get the locale from the OS and set LANG. */
> +{
> +  NSLocale *locale = [NSLocale currentLocale];
> +
> +  NSTRACE ("ns_init_locale");
> +
> +  @try
> +    {
> +      /* Set LANG to locale, but not if LANG is already set. */
> +      setenv("LANG", [[locale localeIdentifier] UTF8String], 0);
> +    }
> +  @catch (NSException *e)
> +    {
> +      NSLog (@"Locale detection failed: %@: %@", [e name], [e reason]);
> +    }
> +}
> +
> +
> +void
>  ns_release_object (void *obj)
>  /*
> --------------------------------------------------------------------------
>      Release an object (callable from C)
> --
> 2.5.4 (Apple Git-61)
>
>
>
> --
> Alan Third
>
>

[-- Attachment #2: Type: text/html, Size: 5137 bytes --]

Re: bug#22392: Emacs OS X GUI doesn't set locale

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

On Mon, Feb 01, 2016 at 06:03:30AM +0100, Anders Lindgren wrote:
> Hi!
> 
> Today, I tested this patch on OS X and GNUstep. From what I can see, it
> applies cleanly and work as intended.

I'm glad you were able to test it on GNUStep. I was reasonably sure it
would work, but couldn't check it.

> I suggest that we apply this patch, so that it will be included in the next
> Emacs 25 pretest.

I don't know if my copyright assignment has gone through yet. I've not
heard anything back. I guess that might hold things up?

-- 
Alan Third

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Emacs OS X GUI doesn't set locale

[Eli Zaretskii]

> Date: Mon, 1 Feb 2016 06:03:30 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>, 22392@debbugs.gnu.org, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Today, I tested this patch on OS X and GNUstep. From what I can see, it applies cleanly and work as
> intended.
> 
> As the LANG variable is set early in the initialisation process, it will be propagated to `process-environment'
> and thus set for all processes started by Emacs.
> 
> I suggest that we apply this patch, so that it will be included in the next Emacs 25 pretest.

I won't argue with that any more, but I must say that I'm uneasy with
this change.  I'd be much happier if we could push LANG into Emacs's
own environment without affecting process-environment.

Paul argued that we already do something similar on MS-Windows, which
is true, but native Windows programs don't look at LANG unless
specifically made to do so in application code, so that setting is
unlikely to affect many programs on Windows.  By contrast, OS X is
(AFAIK) a BSD-ish system, so I expect much more programs to change
their behavior when LANG is set to something that suits Emacs, but is
not necessarily "right" for the rest of the system.

That's all I have to say; if you are still OK with doing that, please
go ahead.

Thanks.

Re: Emacs OS X GUI doesn't set locale

[Alan Third]

Anders Lindgren <andlind@gmail.com> writes:

> Hi,
>
> This sounds like a good change. Unfortunately, I can't answer the
> locale-questions you raised in the mail. However, I have a few small
> questions:
>
> * Why a separate source file? Is there any technical reasons why this
> couldn't reside in, say, nsterm.m?

No, I just wasn't sure what the deal was with including files like that
in emacs.c since there's quite a lot in it. If that's an acceptable way
to do it then I'd be happy to do so.

> * Can you add a "NSTRACE" line to the function, so that it's clear
> when this function is called, when NSTRACE is enabled.

I don't know what that means, but I'll look into it.

> * Have you considered populating `process-environment' instead of
> setting LANG in the Emacs process? Would there be any
> advantages/disadvantages with this approach?

The problem is that Emacs itself doesn't know what the correct locale is
and therefore sets various encodings and things to "nil". As far as I
can tell process-environment is only for sub-processes, which doesn't
solve this particular problem.
-- 
Alan Third

Re: Emacs OS X GUI doesn't set locale

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

>
> > * Why a separate source file? Is there any technical reasons why this
> > couldn't reside in, say, nsterm.m?
>
> No, I just wasn't sure what the deal was with including files like that
> in emacs.c since there's quite a lot in it. If that's an acceptable way
> to do it then I'd be happy to do so.
>

Ah, I see. Including "nsterm.h" from "emacs.c" sounds like a bad idea, as
it would increase the rebuild times. In this case, introducing a new source
file seems like the right choice.



> > * Can you add a "NSTRACE" line to the function, so that it's clear
> > when this function is called, when NSTRACE is enabled.
>
> I don't know what that means, but I'll look into it.
>

It's a simple printf-based macro that prints a call stack of all NS-related
function calls. The resulting log looks like:

nsterm.m  : 1399: [   70]  x_make_frame_visible
nsterm.m  : 6569: [   71]  | [EmacsView windowDidBecomeKey]
nsterm.m  : 1360: [   72]  | | ns_frame_rehighlight
nsterm.m  : 2048: [   73]  | | | x_set_frame_alpha
nsterm.m  : 7775: [   74]  | [EmacsWindow constrainFrameRect:(X:0
Y:684)/(W:595 H:516) toScreen:]
nsterm.m  : 7123: [   75]  | | [EmacsView isFullscreen] ->> 0

Simply include "nsterm.h" and add the following line:

      NSTRACE ("init_environment");

You can enable tracing by uncommenting the line defining NSTRACE_ENABLED in
nsterm.h.


> * Have you considered populating `process-environment' instead of
> > setting LANG in the Emacs process? Would there be any
> > advantages/disadvantages with this approach?
>
> The problem is that Emacs itself doesn't know what the correct locale is
> and therefore sets various encodings and things to "nil". As far as I
> can tell process-environment is only for sub-processes, which doesn't
> solve this particular problem.
>

OK, then setting "LANG" in the Emacs process is the correct way to do it.



Thanks for finding and fixing this!

    -- Anders

[-- Attachment #2: Type: text/html, Size: 3448 bytes --]

Re: Emacs OS X GUI doesn't set locale

[Eli Zaretskii]

> Date: Wed, 27 Jan 2016 07:21:41 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22392@debbugs.gnu.org, emacs-devel <emacs-devel@gnu.org>
> 
>     > * Why a separate source file? Is there any technical reasons why this
>     > couldn't reside in, say, nsterm.m?
>     
>     No, I just wasn't sure what the deal was with including files like that
>     in emacs.c since there's quite a lot in it. If that's an acceptable way
>     to do it then I'd be happy to do so.
> 
> Ah, I see. Including "nsterm.h" from "emacs.c" sounds like a bad idea, as it
> would increase the rebuild times.

Why is that?  We already include nsterm.h in at least 2 other *.c
files, so why would a third one matter so much?

> In this case, introducing a new source file seems like the right
> choice.

I'd rather avoid a new file, especially as it's going to be very
small.

Thanks.