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