As @maan2003 noted in #18473, we should warn the user if direnv call
fails
Release Notes:
- Show a notice in the activity indicator if an error occurs while
loading the shell environment
Before this we we would stop loading the environment if the call to
direnv failed, which is not necessary in any way
cc @mrnugget
Release Notes:
- Fixed the environment not loading if `direnv` mode is set to `direct`
and `.envrc` is not allowed
This is a follow-up to #17075 to spawn a login shell when getting the
environment for projects.
The reason why we didn't do it before is that we only used the
environment for certain language servers and not a lot of other things,
like tasks.
But with #17075 we now use the project more often and use it as the
_base_ environment for tasks/terminals.
Before the change, terminals and tasks would inherit the Zed process'
environment, including PATH and so on. After the change, we would set
the environment, overwriting the PATH instead of merging. But the
non-login shell environment is a subset of the login-shell environment.
Release Notes:
- Fixed environment variables used per project in terminals/tasks
overwriting the base environment and not making use of a login-shell
environment.
This changes the Zed CLI `zed` to pass along the environment to the Zed
project that it opens (if it opens a new one).
In projects, this CLI environment will now take precedence over any
environment that's acquired by running a login shell in a projects
folder.
The result is that `zed my/folder` now always behaves as if one would
run `zed --foreground` without any previous Zed version running.
Closes#7894Closes#16293
Related issues:
- It fixes the issue described in here:
https://github.com/zed-industries/zed/issues/4977#issuecomment-2305272027
Release Notes:
- Improved the Zed CLI `zed` to pass along the environment as it was on
the CLI to the opened Zed project. That environment is then used when
opening new terminals, spawning tasks, or language servers.
Specifically:
- If Zed was started via `zed my-folder`, a terminal spawned with
`workspace: new terminal` will inherit these environment variables that
existed on the CLI
- Specific language servers that allow looking up the language server
binary in the environments `$PATH` (such as `gopls`, `zls`,
`rust-analyzer` if configured, ...) will look up the language server
binary in the CLI environment too and use that environment when starting
the process.
- Language servers that are _not_ found in the CLI environment (or
configured to not be found in there), will be spawned with the CLI
environment in case that's set. That means users can do something like
`RA_LOG=info zed .` and it will be picked up the rust-analyzer that was
spawned.
Demo/explanation:
https://github.com/user-attachments/assets/455905cc-8b7c-4fc4-b98a-7e027d97cdfa
