bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 29 Jun 2016 09:12:39 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> On Wed, Jun 22, 2016 at 10:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > In any case, doing that would mean a much larger job, even if it's
> > possible.  E.g., how do you deal with Lisp code that expects
> > (expand-file-name "~") and (getenv "HOME") to yield the same value?
> 
> Hmm, so it's easy enough to move setting of both Vprocess_environment
> and Vinitial_environment before the Windows code starts adding to the
> environment.

I'd actually suggest doing it the other way around: move the
Windows-specific code in w32.c that pushes these variables into the
environment after Vprocess_environment and Vinitial_environment were
already computed.  That way, we are sure the only affected platform is
w32.  (Order of initialization at startup matters, so best not to rock
the boat there, unless we absolutely have to.)

> And getenv would have to be modified to consult Emacs'
> environment so that that (expand-file-name "~") and (getenv "HOME")
> give the same values.

C 'getenv' or Lisp 'getenv'?

> But it seems we would then need 2 sets of functions: getenv/setenv and
> get-subproc-env/set-subproc-env (the latter working on
> Vprocess_environment only). This feels like a complication with not
> much benefit.

We already have that: there's 'getenv' and 'egetenv' on the C level.
And the Lisp 'setenv' is already documented to modify
process-environment.  So I'm not sure I see the problem (although it's
clear that getenv_internal_1 will probably need some Windows specific
changes.)