From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: Emacs OS X GUI doesn't set locale Date: Wed, 27 Jan 2016 07:21:41 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143f394bbd317052a4ad04c X-Trace: ger.gmane.org 1453875711 4320 80.91.229.3 (27 Jan 2016 06:21:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jan 2016 06:21:51 +0000 (UTC) Cc: 22392@debbugs.gnu.org, emacs-devel To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 27 07:21:50 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aOJUB-0005TT-MV for ged-emacs-devel@m.gmane.org; Wed, 27 Jan 2016 07:21:47 +0100 Original-Received: from localhost ([::1]:48275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOJUA-0000Ld-Ol for ged-emacs-devel@m.gmane.org; Wed, 27 Jan 2016 01:21:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOJU7-0000LW-4B for emacs-devel@gnu.org; Wed, 27 Jan 2016 01:21:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOJU6-0006PS-2G for emacs-devel@gnu.org; Wed, 27 Jan 2016 01:21:43 -0500 Original-Received: from mail-vk0-x236.google.com ([2607:f8b0:400c:c05::236]:36488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOJU5-0006PO-SY for emacs-devel@gnu.org; Wed, 27 Jan 2016 01:21:41 -0500 Original-Received: by mail-vk0-x236.google.com with SMTP id n1so105280455vkb.3 for ; Tue, 26 Jan 2016 22:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xqEeLoGltrlwVLYYf4QbSWHZEvtgClfmUkF+oenzRE8=; b=piepn0AcSqEeVvgXllg56SLNFUUdzOJ3NHGPDO05S3h8OI4LZpi54GAdo4eKdrB1qS jQjrYYbKXdWX2XAZw/n9hCLZPyu13hQ1RJ/grMQgGj39rgovYXFg8/XaiTvVNX/hokRO hSsNaChioDFq7q5RVjsXiEw5HBC5OOsisMFai3HrrJB2b/iKnjrp836yufQqggQnezfV 4BzTZy+HXRHsxhuXk/0GmBHJgDGwFSAER1YVcryc1ft4mgvNcgGgs47DGfWVdggZSTUX J5G6pNvPsNLgGxuBK+J82VncSHqRfZWI4n7SQu/0PM4NTzAsbUE57ZI4B0e7zW1WTa8q oSSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xqEeLoGltrlwVLYYf4QbSWHZEvtgClfmUkF+oenzRE8=; b=B8gNaYdkxm+0YabH7QpgzgF2e5T1fKvKR6qFIrOA+DQFMLKa2YMDrHI7SbT5fgvH3X XcOIHc59AEGqRd4PN8FqzG9gVY+TnTH/xLCCOZvuOkQW5h/abPYCMv06bTCeqa/PAlc4 0QNeBYpjs4QLQ8LjpTUab0RTWYUYKo7EaECR7ltIjXfvi+SVa7OXMvXbuB8IOF+86nD8 HhhaoAySzaCaFJEZGPiXGR1UDzw0ujM9pngvpK6TBG7tj2Al/V56wKb4yqaHGtyiWtHr Dkza2grPwsk/aFVQRpjl386+agDqAa9o0Sy8gUQhV1I7bhyb3Q+T/WujCJx4LJCsrpoq gpLw== X-Gm-Message-State: AG10YOTdlsR+EPim9APHJBDZiiDaVrYn5leL8XHDjHL27RX5rsePYeQDC8rxAKaNOzKKJCkR+f+OvsB6DEqFUw== X-Received: by 10.31.173.18 with SMTP id w18mr15080807vke.31.1453875701467; Tue, 26 Jan 2016 22:21:41 -0800 (PST) Original-Received: by 10.31.214.131 with HTTP; Tue, 26 Jan 2016 22:21:41 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198903 Archived-At: --001a1143f394bbd317052a4ad04c Content-Type: text/plain; charset=UTF-8 > > > * 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 --001a1143f394bbd317052a4ad04c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> * Why a separate source file? Is there a= ny technical reasons why this
> couldn't reside in, say, nsterm.m?

No, I just wasn't sure what the deal was with including files li= ke 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, int= roducing a new source file seems like the right choice.

=C2=A0
> * Can you add a &q= uot;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 prin= ts a call stack of all NS-related function calls. The resulting log looks l= ike:

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

Simply include "nsterm.h" and a= dd the following line:

=C2=A0 =C2=A0 =C2=A0 NSTRAC= E ("init_environment");

You can enable t= racing by uncommenting the line defining NSTRACE_ENABLED in nsterm.h.
=


> * Have you considered populating `process-environment' instead of<= br> > 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 l= ocale 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!

=C2=A0 =C2=A0 -- Anders

--001a1143f394bbd317052a4ad04c--