On Thu, 29 Apr 2021 at 10:02, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> So why not make buffer-local process environments an official thing?
>
> Sounds fine to me.
>
> To fix cases like `compile` or `run-python`, I think patches would be
> welcome regardless of what is decided in this discussion: those
> behaviors look like plain bugs to me.

Great!

>
>> # Local Variables:
>> # path: "~/path/to/some/virtualenv/bin"
>> # env: "VIRTUAL_ENV=$HOME/path/to/some/virtualenv"
>> # env: "LANG=C"
>> # End:
>
> A few comments:
> - I don't much like "special local vars" (like `eval` and `mode`), so if
>   we can find a more general solution (i.e. one that can be useful for
>   other settings), that would be better.  Maybe
>
>     # push exec-path: "~/path/to/some/virtualenv/bin"

Some notation equivalent to

# eval: (add-to-list (make-local-variable var) value)

might be handy, as well as checkable for safety.  But in the env var
case it would be important to run `substitute-env-vars', so it's a
special case.

>
> - both `exec-path` and `process-environment` are "dangerous" variables,
>   so encouraging such uses sounds rather risky.

True, but setting the environment for buffers in a project is something
one needs to do all the time.  After confirming once, it has to get out
of the way and just happen automatically.  The details of how this works
of course are worth discussing.

>
> - I'd write `path` above as `exec-path` or `PATH`, or even `$PATH`,
>   otherwise it's unclear which "path" is meant.
>
>> --- a/lisp/progmodes/compile.el
>> +++ b/lisp/progmodes/compile.el
>> @@ -1779,6 +1779,8 @@ compilation-start
>>  	    (replace-regexp-in-string "-mode\\'" "" (symbol-name mode))))
>>  	 (thisdir default-directory)
>>  	 (thisenv compilation-environment)
>> +         (this-process-environment process-environment)
>> +         (env-buffer (when (local-variable-p 'process-environment) (buffer-name)))
>>  	 outwin outbuf)
>>      (with-current-buffer
>>  	(setq outbuf
>> @@ -1856,6 +1858,9 @@ compilation-start
>>  		"; default-directory: "
>>                  (prin1-to-string (abbreviate-file-name default-directory))
>>  		" -*-\n"
>> +                (if env-buffer
>> +                    (format "Process environment is local to buffer `%s'\n" env-buffer)
>> +                  "")
>>  		(format "%s started at %s\n\n"
>>  			mode-name
>>  			(substring (current-time-string) 0 19))
>> @@ -1875,7 +1880,7 @@ compilation-start
>>                (and (derived-mode-p 'comint-mode)
>>                     (comint-term-environment))
>>  	      (list (format "INSIDE_EMACS=%s,compile" emacs-version))
>> -	      (copy-sequence process-environment))))
>> +	      (copy-sequence this-process-environment))))
>>          (setq-local compilation-arguments
>>                      (list command mode name-function highlight-regexp))
>>          (setq-local revert-buffer-function 'compilation-revert-buffer)
>
> Does this work correctly when you `M-x recompile`?

I wasn't aware of recompile.  The attached patch works with it.  The
attached version breaks with Tramp, but I think this is a Tramp bug.

In fact, even without the patch, if I make my `process-environment'
buffer local, then `M-x cd' to a ssh path, then do `M-! env', I see a
mixture of my machine's environment and the remote machine's environment.
For instance, PATH has the local machine value.