From: Eli Zaretskii <eliz@gnu.org>
To: Noam Postavsky <npostavs@users.sourceforge.net>
Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org
Subject: bug#10980: GNU bugs information: logs for bug#10980
Date: Wed, 08 Jun 2016 19:40:24 +0300 [thread overview]
Message-ID: <83twh3r5vr.fsf@gnu.org> (raw)
In-Reply-To: <CAM-tV--g0fZVmZB3y6+Hkqx0cGS9nck0TOj-hHwVdvvAmepq1A@mail.gmail.com> (message from Noam Postavsky on Tue, 7 Jun 2016 23:54:17 -0400)
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 7 Jun 2016 23:54:17 -0400
> Cc: bo.johansson@lsn.se
>
> > My idea to get a read-only "inherited environment" is:
> > 1) To save the "inherited environment" early in "c-code" at start up of
> > Emacs
> > 2) Implement a lisp function which can return the saved "inherited
> > environment".
> >
> > The new read-only "inherited environment" can then later be used to start
> > external processes with a more "transparent" environment.
> > To start to change the current handling of the variable initial-environment
> > is probably difficult and error prone.
> >
>
> I read this as a feature request to let lisp programs be able to see
> the environment from before Emacs startup routines have changed it.
I don't think we want to have environment-related functions that are
specific to Windows, that goes against the goal of portability of
Emacs packages.
I'm okay with considering patches specific to w32 that would eliminate
the need for pushing variables into the environment of subprocesses,
and/or leave initial-environment unaffected by the pushed values, but
no one has stepped forward for the job.
> I have an additional use case for this: in magit it would be useful
> to see if the user has HOME or if they just let Emacs choose a
> default value for it. In the latter case, I would pop up a warning
> to tell them not to do that because git chooses a different default
> value HOME, and having disagreement causes confusion (of the "why
> does X work from command line and not in magit?" variety).
I guess you refer to the fact that msysgit uses $USERPROFILE as the
alternative home directory if $HOME is not set? If so, I'd rather
suggest to report a bug to msysgit maintainers: they are behaving
against platform recommendations. From
https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx:
CSIDL_PROFILE
FOLDERID_Profile
The user's profile folder. A typical path is
C:\Users\username. Applications should not create files or folders
at this level; they should put their data under the locations
referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. However, if you
are creating a new Known Folder the profile root referred to by
CSIDL_PROFILE is appropriate.
If you look in the $USERPROFILE directory on a typical Windows
machine, you won't see there any sub-directory or file created by an
application, only a few standard sub-directories. Applications do
generally follow the above recommendations; for example, I have
Firefox installed, which keeps my customizations in
$APPDATA/Mozilla/Firefox/Profiles/. So Git is the odd one out if it
puts its ~/.gitconfig file in $USERPROFILE.
next prev parent reply other threads:[~2016-06-08 16:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAM-tV-8GBPbR3WO9Y_k6mrWop2ZcJCL16R9R2=zmFU5brRp5+w@mail.gmail.com>
[not found] ` <handler.s.R.14653322689344.info.0@debbugs.gnu.org>
2016-06-08 3:54 ` bug#10980: GNU bugs information: logs for bug#10980 Noam Postavsky
2016-06-08 16:40 ` Eli Zaretskii [this message]
2016-06-21 0:23 ` Noam Postavsky
2016-06-21 13:27 ` Eli Zaretskii
2016-06-21 21:03 ` Noam Postavsky
2016-06-22 2:39 ` Eli Zaretskii
2016-06-22 2:54 ` Noam Postavsky
2016-06-22 14:57 ` Eli Zaretskii
2016-06-29 13:12 ` Noam Postavsky
2016-06-29 15:15 ` Eli Zaretskii
2016-06-29 15:26 ` Noam Postavsky
2016-06-29 15:34 ` Eli Zaretskii
2016-06-29 23:02 ` Noam Postavsky
2016-07-09 10:57 ` Eli Zaretskii
2016-07-18 21:52 ` Noam Postavsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83twh3r5vr.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=10980@debbugs.gnu.org \
--cc=bo.johansson@lsn.se \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.