On 24 Jul 2020, at 20:06, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
The issue is what env vars are visible when `substitute-in-file-name' is
called. That is currently done in gnatcore.el `wisi-compiler-parse-one',
which only includes env vars defined in the project. That's been true
since Sept 2019 when I moved to project.el stuff. So you are remembering
behavior from before that, when it most likely did use the global
process-environment, which includes HOME.
Yes; last changed (but probably not last used, tbf) Feb 2019. In wisi.info, the "Project files" section says: A variable name that starts with @code{$} is set as a process environment variable, for processes launched from Emacs for the project. In values, process environment variables can be referenced using the normal @code{$var} syntax.which supports your expectation; HOME is a process env var.
C-h C-v process-environment:
"Entries in this list take precedence to those in the frame-local environments. Therefore, let-binding ‘process-environment’ is an easy way to temporarily change the value of an environment variable, irrespective of where it comes from. To use ‘process-environment’ to remove an environment variable, include only its name in the list,
which doesn't seem to match the actual behaviour.
I prefer the current implementation; _everything_ needed by the project
is defined in the project, so you don't accidently depend on some
random file referenced via some random env var (I've been bitten by that
many times when moving to another machine) (your next message indicates
you discovered this).
But it probably makes sense to have an option somewhere to say "use
process-environment; I accept the risk". In a .prj file, we could have:
global_env_vars=true
or something similar
Possibly
import_env_var=HOME
?
|