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: Tue, 21 Jun 2016 16:27:54 +0300	[thread overview]
Message-ID: <83d1na7jtx.fsf@gnu.org> (raw)
In-Reply-To: <CAM-tV-8fHB959a5kwuTtEi+owmEim2cjMRPSTHdyVTh38rWMrg@mail.gmail.com> (message from Noam Postavsky on Mon, 20 Jun 2016 20:23:26 -0400)

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Mon, 20 Jun 2016 20:23:26 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> > 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
> 
> 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, something
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?

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.

> > 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.
> 
> To me it makes sense to have $HOME map to $USERPROFILE, and $APPDATA
> is like $XDG_CONFIG_HOME (usually ~/.config/ on GNU/Linux). However,
> this is purely subjective as there are no platform recommendations
> about translating environment variables to other platforms.

I quoted the platform recommendations that discourage putting files
directly under $USERPROFILE, and most programs, including those ported
from Posix platforms, do seem to follow those recommendations.





  reply	other threads:[~2016-06-21 13:27 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
2016-06-21  0:23       ` Noam Postavsky
2016-06-21 13:27         ` Eli Zaretskii [this message]
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=83d1na7jtx.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.