Re: setenv

[Thomas F. Burdick]

miles@gnu.org (Miles Bader) writes:

> tfb@mudslide.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >   (4) getenv and setenv both work on process-environment as they do
> >       now, but before returning, ensure that Emacs' actual environment
> >       reflects the content of this variable.  This will allow the
> >       Elisp user to modify Emacs' own actual environment, won't
> >       require any special knowledge of the system, and won't break any
> >       existing code that may modify process-environment directly.
> 
> This means the the user still has to know about the two sorts of
> environments.  They shouldn't have to think about it at all.

The only reason I'd want to expose
synchronize-environment would be to prevent code like: (let
((process-environment ...))  (getenv "_") ...)

The only time the two environments would be visibly different would be
for a subset of those cases where Emacs works incorrectly now.  Using
getenv/setenv, the user will see one environment, which will be
guaranteed to be in sync with the C environment (which it's not now).
Manipulating process-environment exclusively using let, setq, rplacd,
and rplaca will work correctly when it works now; the fact that there
are two environments is already visible.  The problem is that right
now, there's no work around.  The only time the user will have to
think about synchronize-environment is when Emacs doesn't get it
right.  And even then, the only reason I'd want to expose
synchronize-environment would be to avoid confusing code like:

  (let ((process-environment ...))
    (getenv "_") ...)

in case Emacs got it wrong.

> Having a user-callable `synchronize-environment' function might be
> useful, but I think _only_ as a work-around for cases where the emacs
> internal code doesn't do it yet (which should be considered a bug) -- it
> ought to remain the job of the C primitives to synchronize the
> environments when necessary (note that this is very rare).

We're completely in agreement here.  However, if this bug does come up
again, it would be nice to have a lisp work-around.  Using
synchronize-environment in before advice would be a nice way to fix
such bugs in situations where the user can't modify the C source.  For
example, at the lab I'm composing this message from, a new Emacs gets
installed about every 5 years.  If there's a bug that can't be fixed
by the user, we're stuck with it for quite a while.