[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 <eliz@gnu.org> 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.
Right.
> 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.
- bug#10980: GNU bugs information: logs for bug#10980, Noam Postavsky, 2016/06/07
- bug#10980: GNU bugs information: logs for bug#10980, Eli Zaretskii, 2016/06/08
- bug#10980: GNU bugs information: logs for bug#10980, Noam Postavsky, 2016/06/20
- bug#10980: GNU bugs information: logs for bug#10980, Eli Zaretskii, 2016/06/21
- bug#10980: GNU bugs information: logs for bug#10980,
Noam Postavsky <=
- bug#10980: GNU bugs information: logs for bug#10980, Eli Zaretskii, 2016/06/21
- bug#10980: GNU bugs information: logs for bug#10980, Noam Postavsky, 2016/06/21
- bug#10980: GNU bugs information: logs for bug#10980, Eli Zaretskii, 2016/06/22
- bug#10980: GNU bugs information: logs for bug#10980, Noam Postavsky, 2016/06/29
- bug#10980: GNU bugs information: logs for bug#10980, Eli Zaretskii, 2016/06/29
- bug#10980: GNU bugs information: logs for bug#10980, Noam Postavsky, 2016/06/29
- bug#10980: GNU bugs information: logs for bug#10980, Eli Zaretskii, 2016/06/29
- bug#10980: GNU bugs information: logs for bug#10980, Noam Postavsky, 2016/06/29