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

bug#22392: 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 --]

bug#22392: 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?

bug#22392: 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 --]

bug#22392: 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.

bug#22392: 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 --]

bug#22392: 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

bug#22392: 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

bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale

[Alan Third]

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

When Emacs is run from the OS X GUI (the dock, spotlight, finder, etc.)
in OS X it doesn't set the locale correctly.

Here's the output of C-h C RET on my machine with no user configuration:

Coding system for saving this buffer:
  Not set locally, use the default.
Default coding system (for new files):
  nil
Coding system for keyboard input:
  = -- no-conversion (alias: binary)

Coding system for terminal output:
  nil
Coding system for inter-client cut and paste:
  nil
Defaults for subprocess I/O:
  decoding: U -- utf-8-unix (alias: mule-utf-8-unix)

  encoding: U -- utf-8-unix (alias: mule-utf-8-unix)


Priority order for recognizing coding systems when reading files:
  1. utf-8 (alias: mule-utf-8)
  2. iso-2022-7bit 
  3. iso-latin-1 (alias: iso-8859-1 latin-1)
  4. iso-2022-7bit-lock (alias: iso-2022-int-1)
  5. iso-2022-8bit-ss2 

I've snipped off the rest, if you want it I can provide it.

Emacs relies on LC_ALL, LC_CTYPE or LANG being set, and OS X's terminal
application sets the LANG environment variable. OS X doesn't set any of
these variables when the application is run from the GUI.

Additionally, Emacs detects when it's being run from the OS X terminal
(mule-cmds.el line 2722) and hard-codes some settings.

The Windows version of Emacs has a similar problem and solves this by
running an "init_environment" function from main in emacs.c that uses
the Windows APIs to set the LANG variable. (as described at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3221#32)

I've written a patch that copies this functionality but for NextStep.
c-h C RET gives:

Coding system for saving this buffer:
  Not set locally, use the default.
Default coding system (for new files):
  1 -- iso-latin-1-unix (alias: iso-8859-1-unix latin-1-unix)

Coding system for keyboard input:
  1 -- iso-latin-1-unix (alias: iso-8859-1-unix latin-1-unix)

Coding system for terminal output:
  1 -- iso-latin-1-unix (alias: iso-8859-1-unix latin-1-unix)

Coding system for inter-client cut and paste:
  nil
Defaults for subprocess I/O:
  decoding: U -- utf-8-unix (alias: mule-utf-8-unix)

  encoding: U -- utf-8-unix (alias: mule-utf-8-unix)


Priority order for recognizing coding systems when reading files:
  1. iso-latin-1 (alias: iso-8859-1 latin-1)
  2. utf-8 (alias: mule-utf-8)
  3. iso-2022-7bit 
  4. iso-2022-7bit-lock (alias: iso-2022-int-1)
  5. iso-2022-8bit-ss2 

Which looks better to me. It also gives me A4 paper instead of legal and
ispell/hunspell is better behaved.


[-- Attachment #2: NS environment patch --]
[-- 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: 15339 bytes --]




In GNU Emacs 25.0.50.1 (x86_64-apple-darwin15.2.0, NS appkit-1404.34 Version 10.11.2 (Build 15C50))
 of 2016-01-16 built on galloway.idiocy.org
Repository revision: a0d5b7ae3bb014bb0b1c205d123c597df0e76411
Windowing system distributor 'Apple', version 10.3.1404
Configured features:
JPEG IMAGEMAGICK ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  locale-coding-system: utf-8

Major mode: Text

Minor modes in effect:
  global-flycheck-mode: t
  flycheck-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
.emacs.d/elpa/seq-20151028.759/seq.el: Pattern t is deprecated.  Use `_' instead [4 times]
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Making completion list...
Quit
Making completion list...

Load-path shadows:
/Users/alan/.emacs.d/elpa/magit-20160116.333/magit-popup hides /Users/alan/.emacs.d/elpa/magit-popup-20160107.437/magit-popup
/Users/alan/.emacs.d/elpa/org-20160111/ox hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox
/Users/alan/.emacs.d/elpa/org-20160111/ox-texinfo hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-texinfo
/Users/alan/.emacs.d/elpa/org-20160111/ox-publish hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-publish
/Users/alan/.emacs.d/elpa/org-20160111/ox-org hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-org
/Users/alan/.emacs.d/elpa/org-20160111/ox-odt hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-odt
/Users/alan/.emacs.d/elpa/org-20160111/ox-md hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-md
/Users/alan/.emacs.d/elpa/org-20160111/ox-man hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-man
/Users/alan/.emacs.d/elpa/org-20160111/ox-latex hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-latex
/Users/alan/.emacs.d/elpa/org-20160111/ox-icalendar hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-icalendar
/Users/alan/.emacs.d/elpa/org-20160111/ox-html hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-html
/Users/alan/.emacs.d/elpa/org-20160111/ox-beamer hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-beamer
/Users/alan/.emacs.d/elpa/org-20160111/ox-ascii hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-ascii
/Users/alan/.emacs.d/elpa/org-20160111/org hides /Applications/Emacs.app/Contents/Resources/lisp/org/org
/Users/alan/.emacs.d/elpa/org-20160111/org-w3m hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-w3m
/Users/alan/.emacs.d/elpa/org-20160111/org-version hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-version
/Users/alan/.emacs.d/elpa/org-20160111/org-timer hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-timer
/Users/alan/.emacs.d/elpa/org-20160111/org-table hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-table
/Users/alan/.emacs.d/elpa/org-20160111/org-src hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-src
/Users/alan/.emacs.d/elpa/org-20160111/org-rmail hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-rmail
/Users/alan/.emacs.d/elpa/org-20160111/org-protocol hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-protocol
/Users/alan/.emacs.d/elpa/org-20160111/org-plot hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-plot
/Users/alan/.emacs.d/elpa/org-20160111/org-pcomplete hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-pcomplete
/Users/alan/.emacs.d/elpa/org-20160111/org-mouse hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-mouse
/Users/alan/.emacs.d/elpa/org-20160111/org-mobile hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-mobile
/Users/alan/.emacs.d/elpa/org-20160111/org-mhe hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-mhe
/Users/alan/.emacs.d/elpa/org-20160111/org-macs hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-macs
/Users/alan/.emacs.d/elpa/org-20160111/org-macro hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-macro
/Users/alan/.emacs.d/elpa/org-20160111/org-loaddefs hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-loaddefs
/Users/alan/.emacs.d/elpa/org-20160111/org-list hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-list
/Users/alan/.emacs.d/elpa/org-20160111/org-irc hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-irc
/Users/alan/.emacs.d/elpa/org-20160111/org-install hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-install
/Users/alan/.emacs.d/elpa/org-20160111/org-inlinetask hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-inlinetask
/Users/alan/.emacs.d/elpa/org-20160111/org-info hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-info
/Users/alan/.emacs.d/elpa/org-20160111/org-indent hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-indent
/Users/alan/.emacs.d/elpa/org-20160111/org-id hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-id
/Users/alan/.emacs.d/elpa/org-20160111/org-habit hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-habit
/Users/alan/.emacs.d/elpa/org-20160111/org-gnus hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-gnus
/Users/alan/.emacs.d/elpa/org-20160111/org-footnote hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-footnote
/Users/alan/.emacs.d/elpa/org-20160111/org-feed hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-feed
/Users/alan/.emacs.d/elpa/org-20160111/org-faces hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-faces
/Users/alan/.emacs.d/elpa/org-20160111/org-eshell hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-eshell
/Users/alan/.emacs.d/elpa/org-20160111/org-entities hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-entities
/Users/alan/.emacs.d/elpa/org-20160111/org-element hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-element
/Users/alan/.emacs.d/elpa/org-20160111/org-docview hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-docview
/Users/alan/.emacs.d/elpa/org-20160111/org-datetree hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-datetree
/Users/alan/.emacs.d/elpa/org-20160111/org-ctags hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-ctags
/Users/alan/.emacs.d/elpa/org-20160111/org-crypt hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-crypt
/Users/alan/.emacs.d/elpa/org-20160111/org-compat hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-compat
/Users/alan/.emacs.d/elpa/org-20160111/org-colview hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-colview
/Users/alan/.emacs.d/elpa/org-20160111/org-clock hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-clock
/Users/alan/.emacs.d/elpa/org-20160111/org-capture hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-capture
/Users/alan/.emacs.d/elpa/org-20160111/org-bibtex hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-bibtex
/Users/alan/.emacs.d/elpa/org-20160111/org-bbdb hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-bbdb
/Users/alan/.emacs.d/elpa/org-20160111/org-attach hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-attach
/Users/alan/.emacs.d/elpa/org-20160111/org-archive hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-archive
/Users/alan/.emacs.d/elpa/org-20160111/org-agenda hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-agenda
/Users/alan/.emacs.d/elpa/org-20160111/ob hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob
/Users/alan/.emacs.d/elpa/org-20160111/ob-tangle hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-tangle
/Users/alan/.emacs.d/elpa/org-20160111/ob-table hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-table
/Users/alan/.emacs.d/elpa/org-20160111/ob-sqlite hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-sqlite
/Users/alan/.emacs.d/elpa/org-20160111/ob-sql hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-sql
/Users/alan/.emacs.d/elpa/org-20160111/ob-shen hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-shen
/Users/alan/.emacs.d/elpa/org-20160111/ob-screen hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-screen
/Users/alan/.emacs.d/elpa/org-20160111/ob-scheme hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-scheme
/Users/alan/.emacs.d/elpa/org-20160111/ob-scala hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-scala
/Users/alan/.emacs.d/elpa/org-20160111/ob-sass hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-sass
/Users/alan/.emacs.d/elpa/org-20160111/ob-ruby hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ruby
/Users/alan/.emacs.d/elpa/org-20160111/ob-ref hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ref
/Users/alan/.emacs.d/elpa/org-20160111/ob-R hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-R
/Users/alan/.emacs.d/elpa/org-20160111/ob-python hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-python
/Users/alan/.emacs.d/elpa/org-20160111/ob-plantuml hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-plantuml
/Users/alan/.emacs.d/elpa/org-20160111/ob-picolisp hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-picolisp
/Users/alan/.emacs.d/elpa/org-20160111/ob-perl hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-perl
/Users/alan/.emacs.d/elpa/org-20160111/ob-org hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-org
/Users/alan/.emacs.d/elpa/org-20160111/ob-octave hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-octave
/Users/alan/.emacs.d/elpa/org-20160111/ob-ocaml hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ocaml
/Users/alan/.emacs.d/elpa/org-20160111/ob-mscgen hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-mscgen
/Users/alan/.emacs.d/elpa/org-20160111/ob-maxima hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-maxima
/Users/alan/.emacs.d/elpa/org-20160111/ob-matlab hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-matlab
/Users/alan/.emacs.d/elpa/org-20160111/ob-makefile hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-makefile
/Users/alan/.emacs.d/elpa/org-20160111/ob-lob hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-lob
/Users/alan/.emacs.d/elpa/org-20160111/ob-lisp hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-lisp
/Users/alan/.emacs.d/elpa/org-20160111/ob-lilypond hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-lilypond
/Users/alan/.emacs.d/elpa/org-20160111/ob-ledger hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ledger
/Users/alan/.emacs.d/elpa/org-20160111/ob-latex hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-latex
/Users/alan/.emacs.d/elpa/org-20160111/ob-keys hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-keys
/Users/alan/.emacs.d/elpa/org-20160111/ob-js hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-js
/Users/alan/.emacs.d/elpa/org-20160111/ob-java hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-java
/Users/alan/.emacs.d/elpa/org-20160111/ob-io hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-io
/Users/alan/.emacs.d/elpa/org-20160111/ob-haskell hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-haskell
/Users/alan/.emacs.d/elpa/org-20160111/ob-gnuplot hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-gnuplot
/Users/alan/.emacs.d/elpa/org-20160111/ob-fortran hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-fortran
/Users/alan/.emacs.d/elpa/org-20160111/ob-exp hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-exp
/Users/alan/.emacs.d/elpa/org-20160111/ob-eval hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-eval
/Users/alan/.emacs.d/elpa/org-20160111/ob-emacs-lisp hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-emacs-lisp
/Users/alan/.emacs.d/elpa/org-20160111/ob-dot hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-dot
/Users/alan/.emacs.d/elpa/org-20160111/ob-ditaa hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ditaa
/Users/alan/.emacs.d/elpa/org-20160111/ob-css hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-css
/Users/alan/.emacs.d/elpa/org-20160111/ob-core hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-core
/Users/alan/.emacs.d/elpa/org-20160111/ob-comint hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-comint
/Users/alan/.emacs.d/elpa/org-20160111/ob-clojure hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-clojure
/Users/alan/.emacs.d/elpa/org-20160111/ob-calc hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-calc
/Users/alan/.emacs.d/elpa/org-20160111/ob-C hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-C
/Users/alan/.emacs.d/elpa/org-20160111/ob-awk hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-awk
/Users/alan/.emacs.d/elpa/org-20160111/ob-asymptote hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-asymptote
/Users/alan/.emacs.d/elpa/seq-20151028.759/seq hides /Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/seq

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils paredit flycheck find-func
help-mode rx subr-x seq gv dash exec-path-from-shell finder-inf
autoinsert csv-mode-autoloads gnuplot-autoloads go-mode-autoloads
paredit-autoloads quack-autoloads queue-autoloads typopunct-autoloads
info package epg-config wombat-theme cl-seq unichar easy-mmode
powershell-mode derived compile comint ansi-color ring speedbar sb-image
ezimage dframe easymenu edmacro kmacro cl-loaddefs pcase cl-lib windmove
paren server time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 292894 11471)
 (symbols 48 27242 0)
 (miscs 40 65 228)
 (strings 32 44073 8751)
 (string-bytes 1 1326190)
 (vectors 16 43065)
 (vector-slots 8 757477 4748)
 (floats 8 188 150)
 (intervals 56 211 79)
 (buffers 976 14))

-- 
Alan Third

bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale

[Random832]

Alan Third <alan@idiocy.org> writes:
> Default coding system (for new files):
>   1 -- iso-latin-1-unix (alias: iso-8859-1-unix latin-1-unix)

Is this really appropriate? I'm not sure like the fact that it's not
UTF-8. How does Terminal (and iTerm) know to use UTF-8?

> Priority order for recognizing coding systems when reading files:
>   1. iso-latin-1 (alias: iso-8859-1 latin-1)
>   2. utf-8 (alias: mule-utf-8)

This one also makes me wonder if the encoding specified in
.CFUserTextEncoding/__CF_USER_TEXT_ENCODING should be used for a second
choice. Which may be an encoding that may not map directly to a locale.

bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale

[Alan Third]

Random832 <random832@fastmail.com> writes:

> Alan Third <alan@idiocy.org> writes:
>> Default coding system (for new files):
>>   1 -- iso-latin-1-unix (alias: iso-8859-1-unix latin-1-unix)
>
> Is this really appropriate? I'm not sure like the fact that it's not
> UTF-8.

I don't know if it's appropriate for OS X, but I'm pretty sure it
matches the codings that the Windows port gives me for en_GB (ENG, in
Windows). Besides, surely it's better than 'nil'?

> How does Terminal (and iTerm) know to use UTF-8?

If you load Emacs on OS X from the terminal this code changes some
settings (set-locale-environment in mule-cmds.el):

    (when (eq system-type 'darwin)
      ;; On Darwin, file names are always encoded in utf-8, no matter
      ;; the locale.
      (setq default-file-name-coding-system 'utf-8)
      ;; Mac OS X's Terminal.app by default uses utf-8 regardless of
      ;; the locale.
      (when (and (null window-system)
		 (equal (getenv "TERM_PROGRAM" frame) "Apple_Terminal"))
	(set-terminal-coding-system 'utf-8)
	(set-keyboard-coding-system 'utf-8)))

So I assume this is how running it from the terminal results in more
UTF-8 codings being used. Perhaps this code should kick-in more
generally? I don't know.

The other possibility is that Terminal.app sets LANG to 'en_GB.UTF-8'.
That final part may be the difference we're seeing here?

>> Priority order for recognizing coding systems when reading files:
>>   1. iso-latin-1 (alias: iso-8859-1 latin-1)
>>   2. utf-8 (alias: mule-utf-8)
>
> This one also makes me wonder if the encoding specified in
> .CFUserTextEncoding/__CF_USER_TEXT_ENCODING should be used for a second
> choice. Which may be an encoding that may not map directly to a locale.

I'm afriad I don't know what you're talking about here.

-- 
Alan Third

bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale

[Random832]

On Mon, Jan 18, 2016, at 16:12, Alan Third wrote:
> I don't know if it's appropriate for OS X, but I'm pretty sure it
> matches the codings that the Windows port gives me for en_GB (ENG, in
> Windows). Besides, surely it's better than 'nil'?

Well, I don't have any trouble opening UTF-8 files. I'm incidentally not
sure that it's really appropriate for windows, either - there, it should
be using windows-1252, not iso-latin-1. I have to wonder how Emacs
behaves on versions of windows whose default codepage is not a trivial
superset of an ISO one. The proper encoding should be able to be
determined by the GetACP function, and should always be a windows
codepage.

> > How does Terminal (and iTerm) know to use UTF-8?
> 
> If you load Emacs on OS X from the terminal this code changes some
> settings (set-locale-environment in mule-cmds.el):

I meant Terminal itself, not Emacs within terminal. For me, it seems to
put LANG=en_US.UTF-8 in the environment.

> The other possibility is that Terminal.app sets LANG to 'en_GB.UTF-8'.
> That final part may be the difference we're seeing here?

Yes, I think so. I was wondering also if there's some hidden setting
that tells Terminal whether to use UTF-8 or not - I don't think it used
it in the earliest versions of OSX.

> > This one also makes me wonder if the encoding specified in
> > .CFUserTextEncoding/__CF_USER_TEXT_ENCODING should be used for a second
> > choice. Which may be an encoding that may not map directly to a locale.
> 
> I'm afriad I don't know what you're talking about here.

You may have a file .CFUserTextEncoding in your home directory, or an
environment variable __CF_USER_TEXT_ENCODING, specifying a value like
[0x1F5:]0x0:0x0 - the first one (in the environment variable only) is
your user ID, the next is the encoding (0x0 for MacRoman) which Finder
uses for preview of non-UTF8 text files, and the last is the language (0
for English, maybe only US English)

For me this is MacRoman (and works as I described with Finder preview
windows) even though there is no actual Unix locale for MacRoman.

bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale

[Alan Third]

Random832 <random832@fastmail.com> writes:

> On Mon, Jan 18, 2016, at 16:12, Alan Third wrote:
>> I don't know if it's appropriate for OS X, but I'm pretty sure it
>> matches the codings that the Windows port gives me for en_GB (ENG, in
>> Windows). Besides, surely it's better than 'nil'?
>
> Well, I don't have any trouble opening UTF-8 files. I'm incidentally not
> sure that it's really appropriate for windows, either - there, it should
> be using windows-1252, not iso-latin-1. I have to wonder how Emacs
> behaves on versions of windows whose default codepage is not a trivial
> superset of an ISO one. The proper encoding should be able to be
> determined by the GetACP function, and should always be a windows
> codepage.

I realised almost immediately after sending the message that this is
crap. What I was thinking was that in Windows I don't get a UTF-8
coding. You're entirely right.

>> The other possibility is that Terminal.app sets LANG to 'en_GB.UTF-8'.
>> That final part may be the difference we're seeing here?
>
> Yes, I think so. I was wondering also if there's some hidden setting
> that tells Terminal whether to use UTF-8 or not - I don't think it used
> it in the earliest versions of OSX.

There's a setting in Profiles -> Advanced that lets you select UTF-8.
It's UTF-8 by default on my system. If I change it I get just "en_GB".

Just to test I changed my code to append ".UTF-8" on the end of what
it's pulling from the system (so on my machine LANG gets set to
"en_GB.UTF-8", and here's the output from c-H C RET:

Coding system for saving this buffer:
  Not set locally, use the default.
Default coding system (for new files):
  U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for keyboard input:
  U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for terminal output:
  U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for inter-client cut and paste:
  nil
Defaults for subprocess I/O:
  decoding: U -- utf-8-unix (alias: mule-utf-8-unix)

  encoding: U -- utf-8-unix (alias: mule-utf-8-unix)


Priority order for recognizing coding systems when reading files:
  1. utf-8 (alias: mule-utf-8)
  2. iso-2022-7bit 
  3. iso-latin-1 (alias: iso-8859-1 latin-1)
  4. iso-2022-7bit-lock (alias: iso-2022-int-1)
  5. iso-2022-8bit-ss2 

So that does make a difference.

The question is what is the correct behaviour here? I, like you, would
rather get UTF-8 everywhere, but is that the *correct* behaviour for an
unconfigured system run from the GUI?

>> > This one also makes me wonder if the encoding specified in
>> > .CFUserTextEncoding/__CF_USER_TEXT_ENCODING should be used for a second
>> > choice. Which may be an encoding that may not map directly to a locale.

Possibly. I believe there's a way to extract a list of preferred
languages from OS X which are separate from the selected locale. That
may be a better way? Although, thinking about it, languages don't
necessarily map to encodings either.

> You may have a file .CFUserTextEncoding in your home directory, or an
> environment variable __CF_USER_TEXT_ENCODING, specifying a value like
> [0x1F5:]0x0:0x0 - the first one (in the environment variable only) is
> your user ID, the next is the encoding (0x0 for MacRoman) which Finder
> uses for preview of non-UTF8 text files, and the last is the language (0
> for English, maybe only US English)

Ah yes, I have exactly the same as you.
-- 
Alan Third

bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale

[Eli Zaretskii]

> From: Alan Third <alan@idiocy.org>
> Date: Mon, 18 Jan 2016 23:11:43 +0000
> Cc: 22392@debbugs.gnu.org
> 
> Possibly. I believe there's a way to extract a list of preferred
> languages from OS X which are separate from the selected locale. That
> may be a better way? Although, thinking about it, languages don't
> necessarily map to encodings either.

They do in Emacs, see locale-language-names in mule-cmds.el.

bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale

[Eli Zaretskii]

> From: Random832 <random832@fastmail.com>
> Date: Mon, 18 Jan 2016 17:09:02 -0500
> Cc: 22392@debbugs.gnu.org
> 
> I'm incidentally not sure that it's really appropriate for windows,
> either - there, it should be using windows-1252, not iso-latin-1.

I don't remember any complaints about that.  The related code is very
old.

> I have to wonder how Emacs behaves on versions of windows whose
> default codepage is not a trivial superset of an ISO one.

See locale-language-names.  Which locales and codepages did you have
in mind, specifically?

> The proper encoding should be able to be determined by the GetACP
> function, and should always be a windows codepage.

Depends on what the proper encoding will be used for.  In general
Windows has 2 - 3 pertinent codepages at any given time, each one used
for different purposes.  (Emacs also has several coding-systems to set
by default.)

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

[Random832]

Paul Eggert <eggert@cs.ucla.edu> writes:
> 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

AFAIK GnuCash does not do much with subprocesses, so the fact that it
doesn't place the locale in its environment (or use UTF-8) doesn't
provide much useful guidance.

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

[Random832]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

Why wouldn't it be right for the rest of the system? Keep in mind that
99% of the time the only programs that are going to be executing
"BSD-ish" programs are going to be terminal emulators, which also set
LANG.

The main thing _I'm_ not comfortable with is the fact that it _doesn't_
set a UTF-8 locale.

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

[Eli Zaretskii]

> From: Random832 <random832@fastmail.com>
> Date: Fri, 05 Feb 2016 02:12:12 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> Why wouldn't it be right for the rest of the system?

I don't know.  Why don't those programs do that today?

> Keep in mind that 99% of the time the only programs that are going
> to be executing "BSD-ish" programs are going to be terminal
> emulators, which also set LANG.

If you are saying those programs all have bugs, then I find it hard to
believe, and anyway, it isn't Emacs's job to fix bugs all over the
system.

However, if enough use cases will be reported which show that indeed
many programs invoked by Emacs work better with that setting in the
environment, I will change my mind.  No such examples materialized
yet, AFAIR.

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

[Random832]

On Fri, Feb 5, 2016, at 02:32, Eli Zaretskii wrote:
> I don't know.  Why don't those programs do that today?

Why don't which programs do what? Terminal emulators *do* set LANG, as
is being proposed here to have Emacs do likewise. Other programs do not,
in general, execute subprocesses that care about LANG, so the fact that
they don't set LANG doesn't matter any more than that Windows programs
don't set it.

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

[Eli Zaretskii]

> From: Random832 <random832@fastmail.com>
> Cc: 22392@debbugs.gnu.org
> Date: Fri, 05 Feb 2016 02:36:32 -0500
> 
> On Fri, Feb 5, 2016, at 02:32, Eli Zaretskii wrote:
> > I don't know.  Why don't those programs do that today?
> 
> Why don't which programs

The ones you alluded to.

> do what?

Set LANG for themselves.

> Terminal emulators *do* set LANG, as is being proposed here to have
> Emacs do likewise. Other programs do not, in general, execute
> subprocesses that care about LANG, so the fact that they don't set
> LANG doesn't matter any more than that Windows programs don't set
> it.

You can set LANG in the program's environment even if you don't launch
subprocesses, just to have the relevant libc routines adjust their
defaults.  In fact, that's why Emacs does that in the first place.

I'm asking why don't the programs you allude to do that already.  If
they do, then setting LANG in Emacs, and passing that to those
programs as result, might interfere with what those programs already
do.

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

[Random832]

On Fri, Feb 5, 2016, at 04:21, Eli Zaretskii wrote:
> You can set LANG in the program's environment even if you don't launch
> subprocesses, just to have the relevant libc routines adjust their
> defaults.  In fact, that's why Emacs does that in the first place.
> 
> I'm asking why don't the programs you allude to do that already.  If
> they do, then setting LANG in Emacs, and passing that to those
> programs as result, might interfere with what those programs already
> do.

Because they don't need it. Because they don't use LANG at all,
internally or otherwise. Because they use Core Foundation instead of
libc for localization. (Though, for applications we do not have the
source code for, I don't know how we can say for sure that they don't
set LANG - the only way to find out if a process has set an environment
variable is to examine its subprocesses with ps -E.)

If mac gui applications used LANG, then the GUI *would* set them when
launching applications, and we wouldn't be having this discussion.

Emacs is in a fundamentally different category from most gui
applications (and in the same category as terminal emulators) because it
launches BSD-subsystem programs which use libc functions for
localization. It's therefore arguably responsible for providing
appropriate environment locale values for those BSD-subsystem programs.
Most applications *don't* launch BSD-subsystem programs as subprocesses.
Emacs (and e.g. other text editors, such as Vim, which also sets LANG in
os_mac_conv.c:mac_lang_init) and terminal emulators are exceptions to
this.

Half of the *point* of this is to make sure subprocesses (like ispell,
or sort, or a shell in m-x terminal, etc) get the proper locale.

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

[Eli Zaretskii]

> From: Random832 <random832@fastmail.com>
> Cc: 22392@debbugs.gnu.org
> Date: Fri, 05 Feb 2016 12:28:13 -0500
> 
> On Fri, Feb 5, 2016, at 04:21, Eli Zaretskii wrote:
> > You can set LANG in the program's environment even if you don't launch
> > subprocesses, just to have the relevant libc routines adjust their
> > defaults.  In fact, that's why Emacs does that in the first place.
> > 
> > I'm asking why don't the programs you allude to do that already.  If
> > they do, then setting LANG in Emacs, and passing that to those
> > programs as result, might interfere with what those programs already
> > do.
> 
> Because they don't need it. Because they don't use LANG at all,
> internally or otherwise. Because they use Core Foundation instead of
> libc for localization. (Though, for applications we do not have the
> source code for, I don't know how we can say for sure that they don't
> set LANG - the only way to find out if a process has set an environment
> variable is to examine its subprocesses with ps -E.)
> 
> If mac gui applications used LANG, then the GUI *would* set them when
> launching applications, and we wouldn't be having this discussion.
> 
> Emacs is in a fundamentally different category from most gui
> applications (and in the same category as terminal emulators) because it
> launches BSD-subsystem programs which use libc functions for
> localization. It's therefore arguably responsible for providing
> appropriate environment locale values for those BSD-subsystem programs.
> Most applications *don't* launch BSD-subsystem programs as subprocesses.
> Emacs (and e.g. other text editors, such as Vim, which also sets LANG in
> os_mac_conv.c:mac_lang_init) and terminal emulators are exceptions to
> this.
> 
> Half of the *point* of this is to make sure subprocesses (like ispell,
> or sort, or a shell in m-x terminal, etc) get the proper locale.

I see your point, but I think it's largely based on speculations.
Mine is as well, so I see no reason to continue arguing about this.  I
already said that I don't object to making these changes.

bug#22392: 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.

bug#22392: 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.

bug#22392: 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

bug#22392: 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 --]

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 --]

bug#22392: 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.

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

[Alan Third]

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

On Mon, Feb 01, 2016 at 06:03:30AM +0100, Anders Lindgren wrote:
> 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 received confirmation of my copyright assignment today, so if
someone wants to apply the patch, that would be great.

Additionally, if it is applied the documentation should probably be
updated too. There's a bit under General Variables that should read
something like:


On MS-Windows and OS X, if LANG is not already set in the environment
when Emacs starts, Emacs sets it based on the system-wide default
language. This can be set in the 'Regional Settings' Control Panel on
some versions of MS-Windows and in the 'Language and Region' System
Preference on OS X.


Should I recreate the patch with that change in it?

-- 
Alan Third

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

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

[Paul Eggert]

On 02/10/2016 03:57 PM, Alan Third wrote:
> I received confirmation of my copyright assignment today, so if
> someone wants to apply the patch, that would be great.

Thanks, I installed it into the emacs-25 branch.

> Additionally, if it is applied the documentation should probably be
> updated too.

Thanks, I installed a doc update along the lines that you suggested.

bug#22392: 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

bug#22392: 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 --]

bug#22392: 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.