all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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.