bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#22392: Emacs OS X GUI doesn't set locale
Date: Fri, 05 Feb 2016 21:46:10 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]