unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Augusto Stoffel <arstoffel@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	 emacs-devel@gnu.org
Subject: Re: [PATCH] Buffer-local process environments
Date: Sat, 28 Aug 2021 14:28:59 +0200	[thread overview]
Message-ID: <87lf4lkb1w.fsf_-_@gmail.com> (raw)
In-Reply-To: <87v97reubc.fsf@gmx.de> (Michael Albinus's message of "Sun, 09 May 2021 18:38:31 +0200")

[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]

After sleeping on this (for quite a while), I'm pretty confident that
the attached patch gives `compile' a sensible behavior in the presence
of a buffer-local `process-environment'.

Specifically, whenever `compile' is called from a buffer where
`process-environment' is local, the *compilation* buffer inherits the
original buffer's `process-environment' and `exec-path'.  When
`process-environment' is not local in the buffer from which `compile'
is called, any local values of those two variables are killed in the
*compilation* buffer as well.  (There's no check for buffer-localness
of `exec-path' because it's usually misguided to keep it out of sync
with PATH.)

Concerning possible interactions with Tramp, I think the conclusion from
what Michael said previously is: if your buffer is remote, then don't
mess with `process-environment' and set
`tramp-remote-process-environment' instead.  If that is a requirement
imposed on the user, then this patch is free of conflicts with Tramp by
decree.

Still, there is one case, which might be quite specific to my personal
workflow, where I get a problematic interaction with Tramp.  I'm often
editing files locally that I can only compile or run on a heavy-duty
remote host.  So I call, from those local buffers

(let ((default-directory "/ssh:remote-host:/path/to/mirror/of/project"))
  (compile "make"))

With the attached patch, a buffer-local PATH value will leak to the
remote machine, which is almost surely the wrong thing to do.  I've
suggested one solution for this on the Tramp side (using
`tramp-process-environment' itself to block certain variables from
being exported to the remote).  I believe Michael wasn't convinced
this is a good idea.  In any case, there's another solution to this
problem, which is to replace the above by

(let ((default-directory "/ssh:remote-host:/path/to/mirror/of/project"))
      (process-environment (default-value 'process-environment))
  (compile "make"))

This is an okay hurdle to introduce, because it is already needed
anyway for functions that starts a process _without_ changing buffers
first, such as `shell-command'.

I hope this makes sense to everybody and can be merged.  I'd also hope
that the present handling of env vars can serve as a model to be
adopted by most commands that switch buffers and then start a process
in this new buffer, such as the `run-<program>` commands.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-compile-respect-buffer-local-process-environmen.patch --]
[-- Type: text/x-patch, Size: 1584 bytes --]

From e46913ec1f0e3f839dd8a36022095587b1962ac5 Mon Sep 17 00:00:00 2001
From: Augusto Stoffel <arstoffel@gmail.com>
Date: Thu, 29 Apr 2021 12:45:04 +0200
Subject: [PATCH] Make 'compile' respect buffer-local process environment

* lisp/progmodes/compile.el (compilation-start): Use
`process-environment' from original buffer in the compilation process.
---
 lisp/progmodes/compile.el | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index af7b8292b7..1c11b7707e 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1783,6 +1783,8 @@ compilation-start
 	    (replace-regexp-in-string "-mode\\'" "" (symbol-name mode))))
 	 (thisdir default-directory)
 	 (thisenv compilation-environment)
+         (bufferenv (when (local-variable-p 'process-environment)
+                      (cons exec-path process-environment)))
 	 outwin outbuf)
     (with-current-buffer
 	(setq outbuf
@@ -1850,6 +1852,11 @@ compilation-start
         ;; NB: must be done after (funcall mode) as that resets local variables
         (setq-local compilation-directory thisdir)
         (setq-local compilation-environment thisenv)
+        (if bufferenv
+            (setq-local exec-path (car bufferenv)
+                        process-environment (cdr bufferenv))
+          (kill-local-variable 'exec-path)
+          (kill-local-variable 'process-environment))
 	(if highlight-regexp
             (setq-local compilation-highlight-regexp highlight-regexp))
         (if (or compilation-auto-jump-to-first-error
-- 
2.31.1


  reply	other threads:[~2021-08-28 12:28 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29 10:56 Buffer-local process environments Augusto Stoffel
2021-04-29 12:30 ` Eli Zaretskii
2021-04-29 12:40   ` Augusto Stoffel
2021-04-29 12:52     ` Eli Zaretskii
2021-04-29 13:06       ` Augusto Stoffel
2021-04-29 14:02 ` Stefan Monnier
2021-04-29 17:26   ` Augusto Stoffel
2021-04-29 17:34     ` Michael Albinus
2021-04-30  7:29       ` Augusto Stoffel
2021-04-30  7:48         ` Michael Albinus
2021-04-30 15:19           ` Augusto Stoffel
2021-04-30 15:51             ` Michael Albinus
2021-05-02  6:13               ` Augusto Stoffel
2021-05-08 17:51                 ` Michael Albinus
2021-05-09  5:06                   ` Augusto Stoffel
2021-05-09 16:38                     ` Michael Albinus
2021-08-28 12:28                       ` Augusto Stoffel [this message]
2021-08-28 12:37                         ` [PATCH] " Eli Zaretskii
2021-08-28 12:55                           ` Augusto Stoffel
2021-09-01 10:42                             ` Stephen Leake
2021-09-01 10:56                               ` Augusto Stoffel
2021-09-01 22:38                                 ` Stephen Leake
2021-09-02  7:14                                   ` Augusto Stoffel
2021-09-06 15:17                                     ` Stephen Leake
2021-08-28 14:06                           ` Arthur Miller
2021-08-28 14:33                             ` Eli Zaretskii
2021-08-28 15:27                               ` Arthur Miller
2021-08-28 15:38                                 ` Eli Zaretskii
2021-08-28 16:48                                   ` Arthur Miller
2021-08-28 15:39                                 ` Augusto Stoffel
2021-08-28 16:43                                   ` Arthur Miller
2021-08-28 12:47                         ` Michael Albinus
2021-08-28 12:59                           ` Augusto Stoffel
2021-08-28 13:18                             ` Michael Albinus
2021-08-28 13:54                               ` Augusto Stoffel
2021-08-28 14:05                               ` Stefan Monnier
2021-08-28 15:19                                 ` Augusto Stoffel
2021-04-30 15:32           ` Augusto Stoffel
2021-04-30 15:55             ` Michael Albinus
2021-04-29 15:37 ` Michael Albinus
2021-04-29 17:31   ` Augusto Stoffel
2021-04-29 17:44     ` Michael Albinus
2021-04-30  7:00       ` Augusto Stoffel
2021-04-30  7:25         ` Michael Albinus
2021-05-02 13:45 ` Stephen Leake

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lf4lkb1w.fsf_-_@gmail.com \
    --to=arstoffel@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=michael.albinus@gmx.de \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).