GNU bug report logs - #22392
25.0.50; NS Emacs run from OS X GUI doesn't set locale

Previous Next

Full log

View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Random832 <random832 <at> fastmail.com>
Cc: 22392 <at> debbugs.gnu.org
Subject: bug#22392: 25.0.50; NS Emacs run from OS X GUI doesn't set locale
Date: Mon, 18 Jan 2016 21:12:31 +0000

Random832 <random832 <at> fastmail.com> writes:

> Alan Third <alan <at> 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

Previous Next

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