[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Noam Postavsky
Subject: bug#10980: GNU bugs information: logs for bug#10980
Date: Tue, 21 Jun 2016 17:03:21 -0400

On Tue, Jun 21, 2016 at 9:27 AM, Eli Zaretskii <address@hidden> wrote:
>> How about splitting apart initialization of Vinitial_environment and
>> Vprocess_environment and moving the former earlier so that it's
>> unaffected by Emacs' manipulations of the environment? See attached
>> patch.
> Thanks.  However, I wonder if we could do better.  First, your patch
> only fixed initial-environment, which means Lisp applications will
> need to explicitly use it, and probably only on Windows,

Well, Lisp applications that want the environment as Emacs originally
received it will use initial-environment regardless of platform
(without the patch, on Windows, they get an environment with some
modifications from Emacs).

> that is not the best solution, IMO.  I hoped we could come up with a
> way of pushing the additional variables into Emacs's own environment
> after Vprocess_environment is already computed -- can you try doing
> that?

I feel like I'm missing some important point here. If these
environment variables won't affect subprocess environments, why set
them at all?

> In any case, the reasons for calling the same function twice in two
> different places should be explained, at least in the comments, or
> else someone might become confused at some future point in time.


> Better yet, perhaps only the Windows build should do something like
> that, and the other platforms could continue using the current code
> mostly unaltered, as they don't need this.

Isn't it simpler to do the same thing on all platforms? They don't
need a different approach, but it doesn't hurt either.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]