Open ericdallo opened 1 year ago
I think I encountered the same with rust-analyzer, but to be sure to repro I'll need to make sure that I can log the folder that's been chosen, I just assumed I had weird Doom shenanigans, and it might still be the case tbh
In upstream Emacs, the process is spawned in default-directory
as working dir ? Is that what we need to check for the fork?
I think so @gagbo , I made a commit on clojure-lsp fixing this on server side, but it'd be nice to follow same emacs standard to avoid issues indeed
I am experiencing something that seems like it may be related. The error message I'm seeing with rust-analyzer
is,
LSP :: rust-analyzer failed to load workspace: "cargo" "--version" failed: No such file or directory (os error 2)
I use direnv
to setup development environments, and it seems like emacs-lsp is finding rust-analyzer
(which is supplied by direnv
in the project directory), but then starting rust-analyzer
itself in the wrong directory.
os error 2 is "file not found", and given that the command that errored is cargo --version
, I suspect that your setup doesn't give a path where cargo
is found by Emacs, rather than rust-analyzer
Yes, but emacs is finding rust-analyzer
which is only available with direnv in the project directory (rust-analyzer
and cargo
are provisioned via nix
). So somehow the server initialization is getting started in the right directory with the right PATH
, and is then going wrong.
I have no such issues with the main branch of emacs.
I think it is caused by the fact that we don't propagate the emacs env. Which ATM is kind of expected with the code as it is.
Yes, I thought it was interesting how clearly the error message suggested that given the direnv interaction. Is the needed change to fill out the SSP_Opts
value in json-rpc-connection
?
If you mean envp in SSP_Opts - I believe the answer is yes.
Is there any temporary/easy workaround for this? My setup is the same as @acowley with direnv
, so I'd need env to be propagated.
I'm probably facing the same issue with lean4, the server complains about unknown project files/modules as if it was spawned in the same directory as the emacs process (instead of default-directory). One simple workaround is to start the emacs process in the project directory itself, the server works perfectly in this setting but it has the caveat I need one emacs process per project. The issue is not present in upstream emacs.
testing with clojure-lsp, it seems that the process is being sapwned from my home dir and not the project root, this probably shows a bug on server side, but other servers may rely on the same