Re: $USERPROFILE for $HOME on W32

["Eli Zaretskii" <eliz@gnu.org>]

> Cc: jasonr@gnu.org, emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 25 Nov 2004 18:43:36 -0500
> 
> > Lisp means, e.g., that temacs will have different ideas about HOME
> > etc. than the dumped Emacs, which I think might confuse someone some
> 
> Huh?  Of course HOME is different before and after the dump.
> How could it be otherwise?

We are emulating a Posix system where HOME's value is something
determined outside Emacs.  If you set HOME in init_environment, it
will be the same before and after dumping, as it is on a Posix system,
since init_environment is called unconditionally in the W32 port, and
called very early in the initialization process, way before the Lisp
interpreter is started and any application-level code runs.

The way you suggested to do it, not only will it be different before
and after the dumping, but it also changes its value in the middle of
loadup, because startup.el is loaded after many other Lisp files.
Such a change is unexpected by any reasonable Emacs hacker, and could
cost someone several hours of useless ``debugging'', or even real bugs
if some preloaded Lisp file references HOME's value.  Why insist on
doing that when there's a cleaner way?  For that matter, is there any
reason at all to favor doing this in Lisp?  I don't think I've heard
even a single reason in favor; did I miss something?

> > This change means that we run this code every time getpwuid is called.
> 
> Right.  Just as we do it on Unix (except on Unix we only do it for HOME
> and not for SHELL).

Unix is a different matter.  The W32 port emulates a single user, so
the values are guaranteed to be constant.  The right way to impement
such emulations is to use static variables initialized only once.

> > and could be avoided if all the
> > environment frobbing were done in C.
> 
> There are many ways to avoid such repetition if it's a problem.
> Moving the initialization to C is one way among many others, so I don't
> think it's a particularly compelling reason.

It's just one of several minor reasons.  I never said your suggestion
was a catastrophe, only that there's a slightly better way.  But if
what I said, and the fact that Jason also preferred doing that in C,
don't convince you, then probably nothing will; I give up.