Re: [PATCH] Buffer-local process environments

[Augusto Stoffel]

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.

>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